Тут я не вижу большей разницы с тем, что называл я (40-50). Но Вы упоминали куда меньшее значение (10) - вот его смысл для меня непонятен.
Идея в том, что пренебрегать "тюнингом" (иначе говоря, вменяемой настройкой) - не стоит. Лучше сэкономить на "железе", чем на администрировании.
Чем что? Чем 100? Чем 40? Из каких соображений у Вас получается именно 10?
Думаю, если нагрузка _резко_ скачет только из-за "логики" приложения - что-то не так в датском королевстве...
С другой стороны - весьма вероятен вариант изменения нагрузки относительно плавно. И в этом случае заставлять ждать запросы в одном месте - крайне нелогично.
На наличие системного администратора.
Если Вы думаете, что мощный сервер автоматически решит все Ваши проблемы - то Вы заблуждаетесь.
Для указанной нагрузки - этого вполне может хвать еще и на все остальное, не только mysql. И даже с избытком. Только для того, чтобы утверждать это со всей определенностью - нужно куда больше информации.
ТС: либо Вы ее предоставляете - либо в тред придут еще любители гадания на кофейной гуще. Их тут предостаточно. Оно точно Вам надо?
Ну, Вы вот писали что число процессов апача доходит до 250. Вот это и есть момент пиковой нагрузки. Слабо верится, что в это время сервер у Вас "шевелится" достаточно шустро и вполне доступен для пользователей.
Кроме того, подобные запросы появляются в выводе mod_status и если нагрузка меняется более плавно. Т.е. в течение суток.
И сколько в среднем? Утром. Днем. Вечером.
Бегите от таких сектантов. Те, у кого прямые руки - без проблем учитывают наличие такой сущности с пользой для себя. WP не исключение, он не настолько паршив.
Против того, чтобы память не была исчерпана апачами - действительно MaxClients работает. Только это и в случае nginx так (КО намекает, что это by design). Разумные лимиты на число апачей должны быть и так и эдак меньше доступной памяти (на сервере есть и другие зверушки кроме апача, а все еще и "шевелиться" должно в пике).
Идея в том, что при наличие второго, более легкого сервера, перед апачем - MaxClients на последнем можно безопасно поставить значительно ниже. За счет чего - я написал. Не до 10, конечно - в этом особого смысла нету (хотя среднее число апачей будет близко к этой цифре, даже ниже). Но и выше 40-50 обычно ставить не имеет смысла. А 50*20Mb - вполне скромно даже для слабенького сервера.
Ставя MaxClients в низкое значение (~< 10) - Вы лишь заставляете клиентов (в пиковые моменты нагрузки) ждать обработки в одном месте. Между тем, как они прекрасно могут это делать в разных местах отработки скриптов - и ради этого можно чуток памяти пожертвовать.
Нужно брать обычный, штатный режим работы. И, конечно, учитывать физические возможности сервера (250*20 ~ 4Gb).
Апач ходит и прибивает своих детей, если считает что они больше не нужны. Подобных запросов много, когда нагрузка скачет. Значит что-то не так...
"если звезды зажигают - значит - это кому-нибудь нужно" (c) Как только апач посчитает что его дочерний процесс/поток больше не нужен - он его удалит. Не удаляет - значит еще нужен.
Почитайте документацию апача, в т.ч. про Max/MinSpareServers - узнаете много полезного и нужного про то как работают разные MPM апача.
Причем тут "метод тыка"? Смотрим на статистику (достаточно посмотреть top на обычное число процессов апача или на информацию mod_status) - и выставляем лимиты в соответствии с ней. Все "строго научно" (тм), никакого тыка.
Запросы и так станут в очередь. Единственное достоинство этого подхода _в среднестатистическом случае_ (хайлоад всякий пока не рассматриваем) - "тяжелые" процессы не висят впустую в памяти, занимаясь запихиванием контента "в трубу" до медленных клиентов. Именно эту роль берет на себя nginx, стоящий перед апачем. Естественно, вместо nginx может быть практически любой современный вебсервере, тотже апач с mod_proxy.
Ну какие тут еще замеры? WP - должно помочь. Сейчас явно кеш используется, мягко говоря - слабо.
Ну, вот именно это я и обозвал "объективными причинами". Рекоммендованный Вами mysql-tunning.sh, кстати, дает в этом отношение хорошее замечание:
Начать с того, что научиться читать:
Это, вообще говоря, универсальная рекоммендация для автоматических "настраивалок".
Чтобы память расходовать на более полезные вещи.
Запомните также, что то значение, которое Вы указали в max-connections - должно быть _осмысленным_. Не только из соображения "быть достаточно большим, чтобы энта ошибка меня не доставала": сервер должен работать в таком режиме и памяти должно хватить _всем_. И mysql, и апачу с php, и nginx, и всему-что-там-еще-у-вас-есть. Включая Вас c sshd, чтобы Вы могли прийти на сервер и вручную разобраться в обстановке.
Зато в разы, в данном случае, - запросто. Особенно, если пишут относительно мало.
Вот и хорошо. Теперь у Вас есть шанс исправить проблему в более приятной обстановке... Вы ведь понимаете, что проблема есть и никуда не делась?
Начните вот с этого, с кеширования. Можно попробовать для начала использовать рекоммендации mysqltuner.pl.
Затем разобраться с этим:
Если не получится избавиться от временных таблиц по объективным причинам - попробуйте использовать tmpfs для временных файлов mysql.
