Тюнинг mysql

nginx-apache-mod_fcgid, memcached, sphinx - всё юзается.

или вы просто не нашли общего языка.

Все-таки взгляд на проблему у вас довольно странный. Вы так и не сформулировали какие именно показатели хотите повысить.

Если просто избавиться от заранее глупых параметров то могу посоветовать

max_connections = 200

query_cache = 64M

Так же нужно разобраться почему у вас mysqltuner ругается на отключенный slow_query_log, но в конфиге эта директива присутствует. Что-то вы неаккуратно запускали и изменяли.

Больше и нечего предложить с такими нечеткими целями.

Да, с myhand не вышло. На нервах, новый год и всё такое... :)

Спасибо за совет, так и сделал, query_cache_size=64M

По поводу slow_query_log.... так же криво было в настройках (это всё после перехода с ветки 5.0 на 5.5, многие параметры изменились/удалились). Исправил.

Теперь надо подождать сутки-двое для сбора статистики. На данный момент вроде нормально:

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.5.19-log

[OK] Operating on 64-bit architecture



-------- Storage Engine Statistics -------------------------------------------

[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 1G (Tables: 20)

[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)

[!!] Total fragmented tables: 4



-------- Security Recommendations  -------------------------------------------

[OK] All database users have passwords assigned



-------- Performance Metrics -------------------------------------------------

[--] Up for: 32m 39s (351K q [179.599 qps], 199 conn, TX: 893M, RX: 46M)

[--] Reads / Writes: 95% / 5%

[--] Total buffers: 692.0M global + 12.4M per thread (300 max threads)

[!!] Maximum possible memory usage: 4.3G (111% of installed RAM)

[OK] Slow queries: 0% (0/351K)

[OK] Highest usage of available connections: 9% (29/300)

[OK] Key buffer size / total MyISAM indexes: 612.0M/608.5M

[OK] Key buffer hit rate: 97.7% (5M cached / 134K reads)

[OK] Query cache efficiency: 65.2% (221K cached / 339K selects)

[OK] Query cache prunes per day: 0

[OK] Sorts requiring temporary tables: 0% (297 temp sorts / 55K sorts)

[OK] Temporary tables created on disk: 0% (0 on disk / 6K total)

[OK] Thread cache hit rate: 85% (29 created / 199 connections)

[OK] Table cache hit rate: 92% (87 open / 94 opened)

[OK] Open file limit used: 4% (115/2K)

[OK] Table locks acquired immediately: 99% (130K immediate / 130K locks)



-------- Recommendations -----------------------------------------------------

General recommendations:

    Run OPTIMIZE TABLE to defragment tables for better performance

    MySQL started within last 24 hours - recommendations may be inaccurate

    Reduce your overall MySQL memory footprint for system stability

А из-за чего всё началось, так это каждые сутки, в разное время вижу таймауты в логах nginx. Их не много, может в процентном соотношении 0.5% от всех запросов, но всёравно мне это не нравится.

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

Буду дальше наблюдать.

Vin_cent, здесь много толковых админов.. Просто праздник на носу)

Попробуйте обратиться к Himiko

Этот клоун просто начал "вонять", когда в ответ на пост в ЛС вида "прихади ка мне в ICQ пагаварим" - я ему вежливо написал, что жду от него описания задачи + бюджета под нее на контакты, указанные в подписи.

В общем, be warned.

А чем вам query_cache не угодил? Он же не per-connection выделяется. Не думаю, что имеет смысл тут жадничать.

Запросто может оказаться "причем" и nginx и апач.

так и не выделяется. это означает, что все параллельные треды блокируются при совместном доступе или очистке кеша. Кеш mysql не такой к каким привыкли веб-программисты. Он очищается и весьма активно при любом изменении затронутых в запросах таблиц.

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

Отсюда и возникает частая ошибка c огромными значениями query_cache_size, а потом казалось бы простейшие запросы тормозят.

На очень конкурентной нагрузке на многопроцессорных серверах с innodb лучше даже вообще отключить кеш или настроить mysql так чтобы кешировались специально помеченные запросы.

Мне понятно куда вы клоните, но тут сильно сгущены краски.

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

Тем не менее, наблюдаю ситуации, когда кеш более чем полезен (размер может быть и поболее указанного выше). И на самописном добре, и на массовых движках.

Размер - не единственная крутилка.

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

http://dom.as/2009/07/08/query-cache-tuning/ . С комментариями обязательно ознакомьтесь.

В общем, пробовать надо.

Ознакомился. Там ссылка на баг #43758 (точнее, на его клон), который поправлен в 5.1.x аж в 16 Jun 2009 11:05.

С Новым Годом! Уже 2012-й на дворе, добро пожаловать из анабиоза. И не читай впредь первые попавшиеся по запросу в гугле блоги - козленочком станешь ;)

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

С наступающим.