Тюнинг mysql

Добрый день!

Извини что вклиниваюсь в топик, но у меня такая ситуация, имеется база размером около 4Г.

Так вот, работает она вполне шустро, но только ~ первый день после service mysql restart, после дня работы начинает заметно подтормаживать (загрузка друпаловских страниц с 3-6 секунд превращается в 20-40) даже ночью, когда народу на сайте крутится в районе 70-100 человек. С чем это может быть связано? Куда смотреть?

Спасибо за ответ

Начиная оттуда где показываются запросы mysql (show processlist). Вы хоть выясните чем mysql занимается в это время - может вообще дело не в нем.

Я что вам уже писал про такие "обобщения" уровня "я ковыряюсь в носу - значит все делают так".

Вот, чуть выше показал, что процентики попадания в кеш - ну никак не коррелируют с его размером. Бывает и так и эдак.

Для начала - в лог медленных запросов.

Включил логгирование, посмотрим, спасибо. Потом отпишу результаты

В общем не стал ждать, включил query_cache_size = 64. Результат:

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 8h 0m 13s (25M q [124.458 qps], 3K conn, TX: 54B, RX: 3B)
[--] Reads / Writes: 96% / 4%
[--] Total buffers: 704.0M global + 16.2M per thread (100 max threads)
[OK] Maximum possible memory usage: 2.3G (59% of installed RAM)
[OK] Slow queries: 0% (0/25M)
[OK] Highest usage of available connections: 44% (44/100)
[OK] Key buffer size / total MyISAM indexes: 512.0M/481.6M
[OK] Key buffer hit rate: 99.9% (422M cached / 292K reads)
[OK] Query cache efficiency: 56.2% (13M cached / 24M selects)
[!!] Query cache prunes per day: 1199426
[OK] Sorts requiring temporary tables: 0% (5K temp sorts / 5M sorts)
[OK] Temporary tables created on disk: 0% (180 on disk / 783K total)
[OK] Thread cache hit rate: 98% (44 created / 3K connections)
[OK] Table cache hit rate: 94% (113 open / 120 opened)
[OK] Open file limit used: 6% (137/2K)
[OK] Table locks acquired immediately: 99% (11M immediate / 11M locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
Variables to adjust:
    query_cache_size (> 64M)

Итог, query_cache_size > 64M в моем случае делает только хуже (сам mysqltuner.pl при >64M советует уменьшить, т.к. не всегда больше значит лучше). Нагрузка на сервере на %20 стала меньше, нежеле чем при 1024М.

Я так понимаю, кэш связан с жестким диском. А на сколько я помню, скорость жесткого диска у меня на дедика не высокая (сам проверить не могу, не знаю, об этом говорил когда-то знакомый админ). Возможно с этим и связано, разность в скорости. А может и вовсе нет..., может просто одинаковых запросов мало идет к mysql (т.к. почти все идет через memcached), поэтому смысл огромного кэша отпадает и делает только хуже.

Смысла в огромном кеше, конечно, нет. А вот в > 64M может и есть. Насколько я помню, mysqltuner.pl начинал ругаться при значениях больших 256M.

Поясните ход мысли? С памятью связан.

Выше я приводил ссылку на блог оракла. Там очень подробно описаны возможные проблемы от большего кеша. Вы бы теперь сравнили с тем, что было у вас в начале (256M).

Не верно оба сказали: http://mysqltuner.pl/mysqltuner.pl

push(@generalrec,"Increasing the query_cache size over 128M may reduce performance");

В общем совету mysqltuner об увеличении query_cache_size нужно относится по ситуации, на счет других его советов вопросов нет.

Так он весь кэш в памяти хранит? Тогда жесткий диск да, не причем.

Категорически неверно.

Правильная последовательность такая:

1) видим ругань на параметр

2) идем читать документацию

3) идем читать багзиллу, хорошие блоги типа percona

4) меняем, смотрим

Ну, если у вас все дико свопиться не начало.

я же говорил тыкая носом myhand в

ну и кто тут ололо ? языком смотрю могёшь молоть...

Да ладно, после его эпического провала со спасением сервера, неумение готовить мискуль уже не удивляет