Это плохо. Ну а man siege полностью осилишь? Взять access.log и долбиться не на одну страничку - на точно так как делают клиенты.
Убедитесь, что запросы от siege не идут мимо вашего "кеша".
Т.е. запрос не отвалился, сервер не возвратил 4** или 5** статус, а что?
Между чем и чем "размер отличается", поясните пожалуйста?
Ну так сделайте 25тыс, в чем конкретно проблема?
Одинаковые. "Все итак работает, а если я замечу проблему - придет валшебник и исправит за 5 минут и 5$" (тм)
Единственная проблема, очевидная из приведенного вами поста - баг в кеше mysql. Повторяю, он исправлен. На каких еще тамошних "ошибках" вы предлагаете мне учиться?
Вот вам более относящаяся к делу ссылка (если кратко, дело вовсе не в блокировках тредов):
http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing
Не имею привычки тратить память бездумно и делать беспричинные глупости.
Где-то были значения и под 256Mb, но обычно << 128Mb. Увеличиваю потихоньку, собираю статистику - смотрю. По результатам - возвращаю все назад или кручу дальше.
Вы поставили задачу "определи мне причину такой-то проблемы" или "посмотри что криминального"?
Например, не берется за задачу, если не может ее выполнить или она глупа.
Может и в этом дело.
Дъявол в мелочах. Не хотите предоставлять информацию - продолжайте надеяться на телепатов.
Тебе не видно?
Может ДНС. Проблема повторялась, если попытаться через несколько минут с того же клиента? Либо тот самый "кеш".
Чудо, man ab осилишь самостоятельно?
Доверять решение проблем тем, кто это умеет. Покуда не стало поздно. Может теперь вы поняли почему люди покупают услуги администрирования, в то время как "все работает"...
Ничего плохого не хочу сказать про systemintegra - но имея явно максимум информации (были на месте) - они не узнали абсолютно ничего существенного. Боюсь, без существенно более полной информации от вас (тот же вывод mod_status на момент проблемы, top, mysql processlist, статистика munin, настройки _всех_ замешанных сервисов от nginx до апача/sql, и т.п. и т.д.) - угадайки от местных телепатов будут еще менее полезны.
"Ссылкам в гугле" не имею привычки верить без достаточных оснований. А то существенное, что там было - как раз подробно откомментировал. Не похоже на принципиальную проблему, а конкретный баг - был исправлен давно.
Причем dotdeb и какие-то "бекпорты"? dotdeb - просто репозитарий пакетов дебиан. Бекпорты давно уже стали официальной частью инфраструктуры debian:
http://backports-master.debian.org/
Вы русским языком все это сформулировать способны, или просто уже запраздновались? Покуда все очень смахивает на "задачу" из области "когда коту делать нечего..."
Если ты не понимаешь зачем тебе это трогать - не трогай.
Ознакомился. Там ссылка на баг #43758 (точнее, на его клон), который поправлен в 5.1.x аж в 16 Jun 2009 11:05.
С Новым Годом! Уже 2012-й на дворе, добро пожаловать из анабиоза. И не читай впредь первые попавшиеся по запросу в гугле блоги - козленочком станешь ;)
Мне понятно куда вы клоните, но тут сильно сгущены краски.
Я наблюдал очень разных, скажем так, "веб программистов". Некоторые "не привыкли" вообще сперва что-то проектировать, прежде чем писать, "не привыкли" читать штатную документацию и т.д.
Тем не менее, наблюдаю ситуации, когда кеш более чем полезен (размер может быть и поболее указанного выше). И на самописном добре, и на массовых движках.
Размер - не единственная крутилка.
Этот клоун просто начал "вонять", когда в ответ на пост в ЛС вида "прихади ка мне в ICQ пагаварим" - я ему вежливо написал, что жду от него описания задачи + бюджета под нее на контакты, указанные в подписи.
В общем, be warned.
А чем вам query_cache не угодил? Он же не per-connection выделяется. Не думаю, что имеет смысл тут жадничать.
Запросто может оказаться "причем" и nginx и апач.
