5 января 2013 г., 9:55 пользователь Eugene Grosbein <eu...@grosbein.net> написал: > 05.01.2013 14:50, greenh пишет: > >>>> 4 января 2013 г., 15:10 пользователь Eugene Grosbein >>>> <eu...@grosbein.net> написал: >>>>> sysctl vfs.ufs | fgrep mem >>>> >>>> vfs.ufs.dirhash_lowmemcount: 0 >>>> vfs.ufs.dirhash_mem: 53137380 >>>> vfs.ufs.dirhash_maxmem: 80646144 >>> >>> Это в момент высокого потребления system time и высокого LA? >>> С одной стороны, упирания в maxmem нет, с другой - текущее потребление >>> dirhash в более чем 50MB это очень много и подтверждает предположение >>> о существовании каталога с огромным количеством файлов. >>> >>> Такие каталоги делают некоторые php-движки, накапливая в них огромное >>> количество устаревших сессионных файлов и пытаясь удалять старые сессии >>> не фоновым процессом, а непосредственно во время обработки юзеровского >>> HTTP-запроса. Этот braindamage лечится только отключением такого поведения >>> движка >>> (чтобы он во время выполения запросов не пытался заниматься посторонними >>> делами >>> типа очистки сессионного каталога) плюс переключением движка на хранение >>> сессий в структуре каталогов вместо одного плоского. A чистку старых сессий >>> выполнять cron'ом. >> >> Нет, это не в момент высокой нагрузки, т.к. ситуация >> стабилизировалась, и поймать ее пока не получается. > > Повторится. > >> Проект действительно содержит огромное количество файлов картинок, >> раскиданых по папкам, и с этим, увы, ничего сделать нельзя. > > Раскиданных по папкам это хорошо. Плохо, когда на UFS в одной папке > очень много файлов, с этим нужно бороться. Либо уходить с UFS, на ZFS > например.
А если во вложенных папках? Вида xx/yy/zz/qq/file_nn.jpg? > >> Сессии проекта представляли собой большую проблемы и давно вынесены в мемкеш > > Тоже вариант (c). Вместо того, чтобы нормализовать работу приложения, можно > обкладываться кешами. Структура проекта такова, что от этого уйти не удалось :(
