Спасибо, использовал LYKANXA9NX7T
Не верно оба сказали: http://mysqltuner.pl/mysqltuner.pl
push(@generalrec,"Increasing the query_cache size over 128M may reduce performance");
В общем совету mysqltuner об увеличении query_cache_size нужно относится по ситуации, на счет других его советов вопросов нет.
Так он весь кэш в памяти хранит? Тогда жесткий диск да, не причем.
Пока я отвечал, ответил ты. Так вышло, что очередность сбилась.
Давай так.
1. Ты хороший специалист, самый умный и всё знаю.
Но давай, ты поменяешь немного тон и интонацию в своих сообщениях. Честно говоря, немного напрягает читать форум с твоими агрессивными комментариями, они отвлекают от сути вопросов.
Если тебя это задело, посмотри в пункт 1.
В общем не стал ждать, включил 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 performanceVariables to adjust: query_cache_size (> 64M)
Итог, query_cache_size > 64M в моем случае делает только хуже (сам mysqltuner.pl при >64M советует уменьшить, т.к. не всегда больше значит лучше). Нагрузка на сервере на %20 стала меньше, нежеле чем при 1024М.
Я так понимаю, кэш связан с жестким диском. А на сколько я помню, скорость жесткого диска у меня на дедика не высокая (сам проверить не могу, не знаю, об этом говорил когда-то знакомый админ). Возможно с этим и связано, разность в скорости. А может и вовсе нет..., может просто одинаковых запросов мало идет к mysql (т.к. почти все идет через memcached), поэтому смысл огромного кэша отпадает и делает только хуже.
Логично. Ответ myhand?
А если поставить апачи 2.4.x, вместо апачи 2.2.x? Преимущества:
- Loadable MPMs
Multiple MPMs can now be built as loadable modules at compile time. The MPM of choice can be configured at run time.
- Reduced memory usage
Despite many new features, 2.4.x tends to use less memory than 2.2.x.
Кто-нибудь пробывал?
p.s. упс, 2.4 ещё нет
Ок, заодно будет опыт. Спустя 48 часов сделаю query_cache_size=64M
Результат выложу.
По умолчанию "general_log" выключен, в конфиге он не включен, поэтому в general-mysql-log ничего не писалось.
По поводу query_cache_size, ткните пожалуйста носом, как определять оптимальный размер?---------- Добавлено в 17:39 ---------- Предыдущее сообщение было в 17:37 ----------
Сайт открывается быстро, connection timeout в логах nginx нет. Но, это сейчас. Я всегда жду наплыва посетителей.
Спасибо за бурное обсуждение.
По моим проектам, оказалось, что mysql не всегда верно выбирает индекс. Например, есть таблица с индексами field, dt.
Запрос "SELECT id FROM table WHERE field='1' ORDER BY dt DESC LIMIT 10" выполнлся достаточно долго (1.5-2.5сек), т.к. оказывается mysql не всегда использует НУЖНЫЙ индекс из возможных. Например в этом запросе он использовал индекс dt. Но стоит в этом типе запросов указать USE INDEX(field), как запрос начинает выполнятся меньше секкунды: SELECT id FROM table USE INDEX(field) WHERE field='1' ORDER BY dt DESC LIMIT 10;
Но, это о птичках... Возвращаясь к конфигу, в итоге после советов и google он приобрел следующий вид:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql tmpdir=/tmp key_buffer=512M table_cache=1024 thread_cache_size = 32 thread_concurrency = 16 max_connections = 100 query_cache_type=1 query_cache_limit=128M query_cache_size=1024M max_allowed_packet = 128M sort_buffer_size = 4M read_buffer_size = 4M join_buffer_size = 4M read_rnd_buffer_size = 4M myisam_sort_buffer_size = 128M max_heap_table_size=128M tmp_table_size=128M concurrent_insert=2 low_priority_updates=1 slow-query-log long_query_time=2 slow_query_log_file=/tmp/slow-queries-log general_log_file = /tmp/general-mysql-log ignore_builtin_innodb default_storage_engine=MyISAM [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
Спустя 5 часов ситуация следующая:
Надо подождать еще сутки-двое, если картина в целом будет аналогичной, то считаю проблемы на данном этапе решены.
Или нет?
Да, с 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 не справляется. Вот и решил покрутить конфиг, но знаний и опыта не имею.
Буду дальше наблюдать.
