Andreas Gruenbacher представил общественности в lkml (linux kernel mailling list) патч для
решения проблемы с кэшированием при резком уменьшении обьема свободной физической памяти.
Проблема в том, что текущая система дискового кэширования пытается забрать под свои нужны столько памяти, сколько можно, а когда
возникает нехватка свободного ОЗУ, дисковый кеш попадает в....... своп !!! Т.е. кэширование оборачивается увеличением нагрузки на диск, предложенный патч решает эту проблему.URL: http://www.kerneltrap.com/node.php?id=373
Новость: https://www.opennet.ru/opennews/art.shtml?num=1411
ты бы хоть разобрался. не может дисковый кэш попадать в своп. и не попадает.
>ты бы хоть разобрался. не может дисковый кэш попадать в своп. и
>не попадает.Что ты, это же Linux. Не должен попадать, но попадает же :-) Насколько я помню в текущих стабильных ядрах выделенная память под кеш не уменьшается _сразу_, а только через определенный таймаут, специальным "чистильщиком", если кому-то срочно нужна память - излишки падают в своп, но реально через буфера в свопе кеширования быть не должно конечно, но опять-так это Linux - и я не удивлюсь если так и есть, иначе зачем создавать подбный патч.
Если не веришь, только что провел на 2.4.15 ядре нехитрый тест.
Есть машинка с 32 Мб ОЗУ. Итак в стационарном состоянии довожу усиленной дисковой активностью размер дискового кеша до 15 Мб. Состояние - в свопе 2 Мб, примерно столькоже свободного ОЗУ. Далее прекращаю операции с диском и запускаю процесс пожиратель памяти (сьедаю 10МБ озу запускаю X'ы) В итоге - размер дискового кеша не изменился, но своп вырос примерно на 11 Мб.
просто внимательно почитай оригинал. и желательно /usr/src/linux/fs/buffer.c, /usr/src/linux/mm/vmscacn.c. а потом уже трынди. из
твоего теста совсем даже не следует, что _кэш_ падает в своп.
Есть такая проблема. Если интенсивно писать в файл, размером например 50 ГБ, то со временем свободное ОЗУ заканчивается (есть 4 ГБ, занято софтом 2 ГБ), потом занимается swap, а далее kernel panic (что-то про ext3).