давайте будем последовательны, в соответствии с предыдущими заявлениями :
вы должны не жадничая выделить по 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.
myhand, раз не хотите учиться на чужих ошибках, мне остается только пожелать вам в новом году набраться собственного опыта и с mysql.
поставьте на всех серверах по 2гб кеша и ждите. на какой-нибудь обязательно начнут жаловаться.
myhand, если конкретно по сценарию возникновения проблемы вам нечего сказать, то придется поверить одной из ссылок в гугле. Разным людям встречаются разные типы нагрузок. Пусть вам не встречались, но теперь вы знаете в чем опасность.
С наступающим.
Значит такие вам случаи попадались. Есть куда более категоричные мнения чем мое.
http://dom.as/2009/07/08/query-cache-tuning/ . С комментариями обязательно ознакомьтесь.
В общем, пробовать надо.
так и не выделяется. это означает, что все параллельные треды блокируются при совместном доступе или очистке кеша. Кеш mysql не такой к каким привыкли веб-программисты. Он очищается и весьма активно при любом изменении затронутых в запросах таблиц.
Традиционные кеши, размер которых можно безболезненно повышать, ведут себя иначе. Туда помещают информацию не всю, а выборочно, которую стоит кешировать.
Отсюда и возникает частая ошибка c огромными значениями query_cache_size, а потом казалось бы простейшие запросы тормозят.
На очень конкурентной нагрузке на многопроцессорных серверах с innodb лучше даже вообще отключить кеш или настроить mysql так чтобы кешировались специально помеченные запросы.
или вы просто не нашли общего языка.
Все-таки взгляд на проблему у вас довольно странный. Вы так и не сформулировали какие именно показатели хотите повысить.
Если просто избавиться от заранее глупых параметров то могу посоветовать
max_connections = 200
query_cache = 64M
Так же нужно разобраться почему у вас mysqltuner ругается на отключенный slow_query_log, но в конфиге эта директива присутствует. Что-то вы неаккуратно запускали и изменяли.
Больше и нечего предложить с такими нечеткими целями.
В большинстве случаев это бесполезное самовнушение. Практически никогда одними настройками не удается изменить ситуацию.
Cначала вы должны четко осознать конечные цели этих манипуляций. По вашим данным не видно даже что вас не устраивает. Медленных запросов мало.
это он почти всегда и предлагает, но увеличение query_cache не должно быть бесконечным. Пожалуй, 64 мб для среднего современного сервера для средних движков должно быть достаточно.---------- Добавлено в 14:19 ---------- Предыдущее сообщение было в 14:13 ----------
А это можно исключить если правильно настроить остальные приложения.
Например, для apache задать MaxClients.
Из изложенного уже можно заметить, что нельзя просто так сходу изменить оптимально пару значений только лишь в mysql.conf. Нужно оценивать сервер в целом и может даже днями и неделями наблюдать за разными показателями.
есть исключения http://support.google.com/webmasters/bin/answer.py?hl=ru&answer=74536
Jeka, рабочий сервер.
ты же не думаешь, что только ради установления этого факта кто-то будет ставить отдельно сервер под openx ?
у меня больше 1 млн крутится, но не представляю как выделить нагрузку именно openx. да и не нужно мне это. он просто незаметный на фоне остальной жести.
Может что-то и было, потому что вышла версия 2.8.8. Но как-то странно об этом объявили не на главной странице.
Может они сами не знают что именно поправили, но поправили на всякий случай работу с html.
Из того, что я вижу в разнице между версиями - более аккуратная обработка alt, но это скорее для борьбы с последствиями взломов, а не в качестве исключения их причины.
Там еще много всего затронуто и сложно сходу понять.
