и какой системный вызов позволяет обычному приложению сбросить кеш ? только злонамеренный скрипт в cron-е из под root или ispamanager такое будет делать, но это слишком фантастично.
все-таки попробуйте аккаунтинг. dump-acct печатает average memory. не обязательно, но какой-то короткоживущий и потребляющий память процесс там должен засветиться.
netwind добавил 16.12.2011 в 13:45
я не это предлагал сделать.
myhand, я нигде не утверждал, что обслуживание это процессы только внутри ядра. обслуживание вообще, в том числе и процессы.
А зачем, вместо того чтобы выдвинуть более конкретную теорию, вы сосредотачиваетесь на оспаривании чужих? часть их них неверные. ну и пусть.
можно попробовать системный аккаунтинг процессов подключить, чтобы понять какой процесс завершается точно в момент сброса кеша. lastcomm пометит процессы, которые завершились из-за core dumped. может быть логи atop что-то успеют показать.
днем сбрасывается чаще чем ночью. скорее само возникает во время обычного обслуживания, чем по крону.
у вас лимиты памяти на все процессы стоят? посмотрите не падают ли апачи или другие процессы
Зачем ? это бесполезно. Если ты не можешь позвонить, то и купить не сможешь.
поправил .
myhand, ну вы поставьте сначала centos, а потом говорите. я первоначально не стал смотреть в сам скрипт, отличия все-таки есть. вы-то зачем вы поверили? с вашей позиции я всегда неправ и нужно все опровергнуть.
в centos 5.7 в скрипте /etc/cron.weekly/99-raid-check нет поддержки ionice.
а сейчас почему все-таки включили БЕЗ поддержки приоритетов?
там все бесхитростно. отличия от дебианов только в частоте проверки.
если в этом и заключается ентерпрайз, то я, пожалуй, пойду.
myhand, потому что мне это кажется глупым. Cкрипт в составе mdadm был очень давно. Ничего не мешало его включить, но побоялись "потому что у нас ентерпрайз и неизвестно как наши клиенты отнесутся к тормозам".
А теперь видимо, обжегшись на молоке, дуют на воду, сделав проверку чаще чем у других.
