Периодически выдает ошибку соединения с БД ((

только из практики. например, делаем такой график http://ww.udaff.com/munin/localdomain/localhost.localdomain-apache_processes.html

и видим, что тут 10 хватает с запасом. единичные всплески munin выравняет.

То есть, maxClients определяем пока не будет достаточно, либо пока будет хватать памяти при условии что процессор не загнется (id=0)?

кеш mysql - далеко не тот тип кешей, к которым привыкли программисты. Настолько не такой, что некоторые сектанты пропагандируют его полное отключение.

Для этого недостаточно просто поставить nginx. Небольшой затык на сервере и вся память будет использована апачами. Низкое значение MaxClients эту ситуацию предотвращает.

Причем тут "метод тыка"? Смотрим на статистику (достаточно посмотреть top на обычное число процессов апача или на информацию mod_status) - и выставляем лимиты в соответствии с ней. Все "строго научно" (тм), никакого тыка.

В периоды максимальной загрузки доходит до установленного максимума (250)

Кстати, а что означают процессы созданные от 127.0.0.1 ? (очень много таких) Это SpareServers?

И еще: если поток создан, он не удаляется а только занимает память?

Бегите от таких сектантов. Те, у кого прямые руки - без проблем учитывают наличие такой сущности с пользой для себя. WP не исключение, он не настолько паршив.

Против того, чтобы память не была исчерпана апачами - действительно MaxClients работает. Только это и в случае nginx так (КО намекает, что это by design). Разумные лимиты на число апачей должны быть и так и эдак меньше доступной памяти (на сервере есть и другие зверушки кроме апача, а все еще и "шевелиться" должно в пике).

Идея в том, что при наличие второго, более легкого сервера, перед апачем - MaxClients на последнем можно безопасно поставить значительно ниже. За счет чего - я написал. Не до 10, конечно - в этом особого смысла нету (хотя среднее число апачей будет близко к этой цифре, даже ниже). Но и выше 40-50 обычно ставить не имеет смысла. А 50*20Mb - вполне скромно даже для слабенького сервера.

Ставя MaxClients в низкое значение (~< 10) - Вы лишь заставляете клиентов (в пиковые моменты нагрузки) ждать обработки в одном месте. Между тем, как они прекрасно могут это делать в разных местах отработки скриптов - и ради этого можно чуток памяти пожертвовать.

Нужно брать обычный, штатный режим работы. И, конечно, учитывать физические возможности сервера (250*20 ~ 4Gb).

Апач ходит и прибивает своих детей, если считает что они больше не нужны. Подобных запросов много, когда нагрузка скачет. Значит что-то не так...

"если звезды зажигают - значит - это кому-нибудь нужно" (c) Как только апач посчитает что его дочерний процесс/поток больше не нужен - он его удалит. Не удаляет - значит еще нужен.

Почитайте документацию апача, в т.ч. про Max/MinSpareServers - узнаете много полезного и нужного про то как работают разные MPM апача.

Сейчас на сервере 48Gb. Используется в данный момент 41Gb

Нагрузка скачет если смотреть в рамках 24-х часов. На протяжении таких интервалов как 1 час - нагрузка равномерная.

В процессе))

Ну, Вы вот писали что число процессов апача доходит до 250. Вот это и есть момент пиковой нагрузки. Слабо верится, что в это время сервер у Вас "шевелится" достаточно шустро и вполне доступен для пользователей.

Кроме того, подобные запросы появляются в выводе mod_status и если нагрузка меняется более плавно. Т.е. в течение суток.

И сколько в среднем? Утром. Днем. Вечером.

Тот сервер начинал задыхаться. На этом больше 170 пока не увидел.

ЗЫ: Спасибо всем за подсказки, немного разобрался, завтра приступлю к практике тонкой настройки. Новый сервер хоть и справляется с нагрузкой при текущих настройках, но все же хочется чтобы он работал в свое удовольствие при своих то возможностях.

ну, это довольно популярное мнение в "хайололоаде" - https://www.google.com/search?hl=en&q=mysql+query+cache+tuner

Но я за то, чтобы они были существенно меньше.

затык может возникнуть из-за блокировок myisam, логики работы приложения и тд. в этом случае один 10секундный всплеск числа апачей отражается в виде плохой работы кеша потом еще час.