Нет, увы.
Но вы хоть выясните, что кто-то туда пишет:
$ inotifywait -m /proc/sys/vm/drop_cachesSetting up watches. Watches established./proc/sys/vm/drop_caches MODIFY /proc/sys/vm/drop_caches OPEN /proc/sys/vm/drop_caches MODIFY /proc/sys/vm/drop_caches CLOSE_WRITE,CLOSE
в то время как ...
# echo 0 > /proc/sys/vm/drop_caches
PS: Кстати, irqbalance я не назвал бы "стандартным" сервисом.
А заработает у вас все на новом сервере, если скрипты заточены под старый PHP? Вы бы лучше об этом задумались.
Можно собрать отдельный php-cgi и запускать нужный скрипт через CGI. Надеюсь, это они (или вы) осилят?
Обновить все, конечно, хорошо. Если единственная причина - жмотство, то жадничать в таких вещах не надо. Сомневаюсь, что администрирование софта в этой устаревшей версии FreeBSD включает установку (и разработку!) исправлений безопасности к ней и т.п.
Более реальную проблему я обрисовал вам выше.
А это - повод сменить "администраторов". Нормальные ничего терять не должны.
Мне было неочевидно - исключили это или нет. Прямого ответа я так и не получил.
Я тоже об этом писал. Но причина выглядит чересчур уж регулярной, так что...
Ну, они там для того и есть - чтобы меняли. Вот бойцы в крон и пихают:
http://www.scottklarr.com/topic/134/linux-how-to-clear-the-cache-from-memory/
"Злонамеренный" скрипт только для вас - для системы это обычное приложение.
Никаких особых сервисов не запущено?
Так вы это проверили или таки нет?
Есть ряд возможностей поиска проблемы, среди них и поиск методом исключений.
Я предложил весьма конкретную теорию - сброс кеша "руками", т.е. приложением. Осталось лишь найти каким.
Если кто-то выжирает память очень быстро - имеет смысл пожестче подкрутить системные лимиты и следить за тем, кто сегфолтится.
Это можно исключить. Управление памятью в linux так тупо не работает.
В смысле, все сбрасывается как и раньше? А крон остановить?
Повторяю, "само" (т.е. в рамках обычного управления памятью ядром) - не может. Нужно, чтобы это какой-то процесс делал.
То что "чаще днем" - не обязательно свидетельствует против крона. Там может быть определенная логика при сбросе кеша - например, проверка определенных показателей типа LA.
Значит кеш явно сбрасывается. По крону - или чем-то иначе запущенным.
Черт его знает - вполне может и ispmanager.
Если есть возможность остановить его процесс - сделайте это и посмотрите.
Не порите чепухи. Я скорее в сторону ispmanager посмотрю - самый плюгавый мейнтейнер в debian на порядок грамотнее разработчиков последнего.
Само - так не бывает. Либо ручками сбрасываете - либо что-то весьма периодически грабастает себе всю память, потому и сбрасывается все.
Быдлопанелька поди какая - или кронтаб, написанный по очередному совету в говноблоге.
"Сложно, но можно" (с) Вполне разумный вариант, который можно просто проверить - вечером там интервалы между пиками порядка часа-получаса получаются. Собрать за такой период подробную статистику с интервалом в несколько секунд. Если ничто память не отожрало - дело явно в другом.
Так памяти навалом остается (около половины). Или думаете что пики "усреднились"?
Пардон, а что сбрасывает? Такое впечатление, будто шаловливыми ручками через /proc/sys/vm/drop_caches.
Никто не "срубит", если вы заранее оговорили объем работ. Если договариваетесь на уровне "сделай мне зашибись" - будет (как правило) недоволен и исполнитель и заказчик.
С учетом того, что дырок на сайте у вас немеряно - он просто использует одну из них. Как явно было при рассылке спама.
Нет такого "запроса". Полный доступ к серверу - это не шутка. При желании и умениях - он позволит обойти любую подобную "защиту". Тем более, если ваши знания и умения, в отличие от нанятого человека - ниже плинтуса.
Сколько вы этому человеку заплатили и за что? Желательно честно. На данном сервере были публичные сервисы (сайты клиентов и т.п.)?
