Тюнинг mysql

"Ссылкам в гугле" не имею привычки верить без достаточных оснований. А то существенное, что там было - как раз подробно откомментировал. Не похоже на принципиальную проблему, а конкретный баг - был исправлен давно.

Не понятно как можно обсуждать , bugs , с версией 5.0 - 5.1 - когда у TC версия 5.5

myhand, раз не хотите учиться на чужих ошибках, мне остается только пожелать вам в новом году набраться собственного опыта и с mysql.

поставьте на всех серверах по 2гб кеша и ждите. на какой-нибудь обязательно начнут жаловаться.

Единственная проблема, очевидная из приведенного вами поста - баг в кеше mysql. Повторяю, он исправлен. На каких еще тамошних "ошибках" вы предлагаете мне учиться?

Вот вам более относящаяся к делу ссылка (если кратко, дело вовсе не в блокировках тредов):

http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing

Не имею привычки тратить память бездумно и делать беспричинные глупости.

Где-то были значения и под 256Mb, но обычно << 128Mb. Увеличиваю потихоньку, собираю статистику - смотрю. По результатам - возвращаю все назад или кручу дальше.

давайте будем последовательны, в соответствии с предыдущими заявлениями :

вы должны не жадничая выделить по 2 гб. плохие движки типа DLE ведь иначе никак не ускорить.

2 гб памяти по с равнению с N*20 мб памяти заблокированных N апачей ведь сущая фигня. По вашем словам вы должны только выиграть.

Вот я вам сообщаю об ошибках : я видел конфигурации, которые необъяснимым образом нестабильно тупили при больших значениях кеша и магическим образом переставали при уменьшении. Почему именно я тоже объяснил. И еще несколько случаев видел на форумах.

Проанализируйте и сделайте выводы - учитесь.

Если меня вам недостаточно, там по ссылке еще Каллаган сказал, что кеш плох и почему.

Вообще говоря, query cache уникальная фича mysql. Больше нигде ее нет.

При низкоконкурентной нагрузке то, что описано по вашей ссылке (http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing) более важно, чем взаимные блокировки. Тут соглашусь.

Баг в mysql связан с зависанием навечно. Конечно, печально, но речь не о нем.

Собственно, чего далеко ходить, вот документация:

http://dev.mysql.com/doc/refman/5.1/en/query-cache.html

и советую точно по ней - 64 мб это как раз ten of megabytes, а 128 - hundreds, которые might not be beneficial.

Только если эти 2Gb будут действительно использоваться.

Во-вторых, не передергивайте, пожалуйста. Я только упомянул, что никакого смысла в изменении размера кеша у ТС - не вижу. Ну разве ради "когда коту делать нечего..."

Боюсь, в магию я тоже не верю. Нужно разбираться и анализировать конкретную конфигурацию. Может дело было именно в баге. Или (более вероятно) в том, что я привел по ссылке выше (дело там не в низкоконкурентной нагрузке).

Не ткнете более конкретно? Что-то не вижу его "ссылки".

Все остальное по вашей ссылке - бездоказательно, увы.

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

*might not be* - вам перевести?

myhand, ну какой же ты нудный.

вот, продиагностируй удаленно . версия 5.5.8, без "бага".

не самая типичная ситуация для хостинга с вечным недостатком памяти, но она встречается у людей с более разнообразным опытом чем у тебя

http://www.sql.ru/forum/actualthread.aspx?bid=6&tid=822926&pg=1

специально выделил важное. в этой ситуации проблемы дизайна query_cache становятся особенно заметны. другие никак не связанные запросы могут тормозиться именно кешем, хотя без него все выполнялось бы параллельно. При большом кеше это становится особенно заметно, но и при маленьком тоже полностью нельзя это явление исключать.

---------- Добавлено в 18:27 ---------- Предыдущее сообщение было в 17:34 ----------

и по своей же ссылке немного не дочитал

http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing

Не нравится - не еште.

Там достаточно сложно однозначно сказать в чем причина. Людям, которые не смотрят вам в рот - может быть заметно.

Проблема, думаю, опять-таки не в "высокооконкурентной" нагрузке - а буквально в том, что описано в документации и блоге оракла.

Что характерно, проблема появилась при обновлении версии mysql. Может буратин тот, кто это сделал?

Комментарии посмотри. Самый первый как раз про это. Для справки: в Debian stable сейчас 5.1.49.

Последний раз напомню:

Уменьшать с 200Mb до 60Mb - в данном случае замена шило на мыло. Абсолютно бессмысленная без измерений и последующего анализа.

Но в точности по советам в официальной документации. ничего авторитетнее документации быть не может по определению. ТС хотел общих и аргументированных советов - вот, пожалуйста.

смотрю

перевожу :

до версии 5.1.33 если запрос использовал SQL_NO_CACHE, результат [в кеше же хранится именно результат] все равно проверялся.

Про остальные случаи, где SQL_NO_CACHE отсутствует в запросе, не написано ничего.

Да и при чем тут комментарии, если в самом блоге в точности подтверждают мои слова.

Как раз напротив. Переведите, пожалуйста:

Вы снова подсократили "перевод". Кстати, как и предыдущую цитату:

О гуру, выделите в этом абзаце ключевое предложение. И сравните затем с тем что процитировали вы.

Я о комментарии упомянул еще и потому, что много воды утекло - часть проблем исправлена. Не случайно боец в вашем примере наткнулся на проблему при обновлении.