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

Чем что? Чем 100? Чем 40? Из каких соображений у Вас получается именно 10?

Думаю, если нагрузка _резко_ скачет только из-за "логики" приложения - что-то не так в датском королевстве...

С другой стороны - весьма вероятен вариант изменения нагрузки относительно плавно. И в этом случае заставлять ждать запросы в одном месте - крайне нелогично.

у меня - 42.

Всё не так. Но ведь у администратора и нет других мер воздействия. Он не сможет переписать приложение. А вот уменьшение MaxClients - сработает.

Тут я не вижу большей разницы с тем, что называл я (40-50). Но Вы упоминали куда меньшее значение (10) - вот его смысл для меня непонятен.

myhand, 10 там подошел бы в том случае, который на графике munin, который я взял для примера. 10 я не советовал.

Интересно, по каким причинам кеширование в WP не подходит?

Видимо слишком динамичный сайт для кеширования. Как то даже были попробовали: поставили Super Cache - вроде все начиналось хорошо, но скоро увидели в браузере вместо внутренней страницы - главную. Больше решили не рисковать. Хотя сама по себе идея кеширования - это хорошая идея.

Вот в примере и советовали, еще как. Объясните почему: лично я не вижу от этого большего выигрыша, в сравнении с консервативным значением ~40-50. Да, апачи не заграбастают порой памяти чуть больше чем Вам хочется - зато обработка запросов не будет насильно стопориться в одном месте.

myhand, согласно тому графику (но не ситуации у ТС) там ничего не стопорится. там даже больше одного апача редко когда нужно.

Интересно, а кто что скажет в отношении параметра key_cache_division_limit ?

По умолчанию стоит 100. Стоит ли менять?

И у меня еще возник вопрос: каким параметром в системе выставдяется ограничение на количество дескрипторов, как узнать текущее значение, и как правильно его определить для себя, каким оно может быть максимальным? Только под мускул насчитал необходимость в 1000 дескрипторах (считал максимальное кол-во соединений помноженное на кол-во используемых таблиц для одного соединения)

Да там пики сглаживаются - вот и все. На месячном графике - вообще _заметен_ всплеск, где работающих воркеров было существенно больше 10.

Ну и зачем тут апача насильно ограничивать, делая из него деревянный nginx? Апач сам нафоркает себе сколько нужно потомков "если что-то немного пойдет не так" (совершенно не обязательно по вине программистов - например просто slashdot-эффект).

Посмотрите документацию, там все достаточно понятно написано: http://dev.mysql.com/doc/refman/5.1/en/midpoint-insertion.html

К сожалению, нет (в принципе) инструкций для домохозяек по изменению этого параметра. Нужно смотреть, экспериментировать - на конкретном примере нагрузки.