А в логах ничего нет, прямо?

Может, io посмотреть ещё?

io примерно такой всегда
http://my.jetscreenshot.com/2772/20130825-h0of-179kb.jpg
В syslog иногда
/USR/SBIN/CRON[14438]: (CRON) error (grandchild #14443 failed with exit status 134)
И апач пару раз просил увеличить MaxClients
На какой именно лог внимание обратить? Есть debug но он 2мб за сутки. Анализировать его сложно просмотром.

а в чем вопрос? что не понятно?

Почему возникает la=30 и при этом потом сервер не приходит в нормальное состояние (если думать что это ыбла такая пиковая нагрузка)? Только после полной перезагрузки. Перезагрузка отдельно апача, mysql, nginx результатов не дает.

Я бы тщательно посмотрел состояние системы в моменты, когда выстраивается большая очередь, определил бы, чем собственно система занята и от этого плясал бы дальше. sar/nmon, top в критическое время и всё такое, наверное

по-моему ты не то диагностируешь.

«нормальное состояние» - это что?

la до 2

с чего ты взял, что la должно быть до 2?

когда ты убиваешь процессы, которые подозреваются и la не уменьшается, сделай вывод всех процессов и их состояний, ищи особенно в состоянии D, про R я думаю ты в курсе. Также смотри внимательно, если юзаешь сетевые fs.

А какое значение la считать нормой? Ясно, что чем меньше процессов ждёт в очереди тем лучше. Для данной системы я принял что меньше 2 - норма.
За 3 недели среднее число процессов в статусе:
R - 4,57 (max - 76)
S - 100,06 (max - 213)
D - 0 (max - 0)

вот ты и решаешь выдуманную задачу, которой нет.

То есть? Считаете что это норма периодически la до 30, а потом постоянная очередь минимум на 5 до ближайшей перезагрузки. Средний WA менее 1,34% по выборке в три недели.

Вообще говоря, для каждой системы свой нормальный load average. Если она нормально выполняет функции, т.е. продолжает обслуживать клиентов, задержки сервиса нет, iowait не приводит к ощутимым service time, то почему нужно считать большой la проблемой?

Другое дело, если при этом всё-таки есть проблемы с сервисом. Тогда надо искать, какого именно ресурса не хватает, что и приводит к большим цыфирям.

Как понять объективно что задержки сервиса нет? Померить 100 раз в час время загрузки конкретной страницы с разных машин, ос, браузеров и вывести среднее время на каждый час. Построить график и посмотреть насколько он ровный в течение суток. Ну субъективно её нет, когда я загружаю страницу сайта, но измерений таких не проводил, трудоёмко и всё равно не объективно. Вот я и мерил задержку в процессах в очереди на обработку, которые мне показывает система.

Увы, с методикой объективной оценки производительности вебового фронта под нагрузкой я не знаком. Мне субъективного метода всегда хватало, для моих скромных нужд, так что тут нужны гуру веб хайлоада :)

Оффтоп

Сорри за оффтоп, подскажи чем графики строишь?

munin

Проверь SMART дисков. Своп, логи и контент апача на одном физическом диске?

Лимиты на память для юзера, под которым запускаются php скрипты выставлены?