Предложения и изменения Mysqltuner в my.cnf

Был ли этот вопрос на Serverfault на несколько дней без везения.

Я запустил mysqltuner.pl на VPS и у вас возникли вопросы относительно предложений об изменениях переменных. Я уверен, что это общие вопросы со сложными ответами.

Я недостаточно осведомлен, чтобы писать запросы и проверять их на сервере, но просто пытаюсь получить немного больше производительности на сервере, который запускает пять сайтов WordPress s > 200 000 просмотров страниц/месяц.

Я оптимизировал базу данных через phpmyadmin (и делаю это регулярно), но тюнер все еще говорит, что есть фрагментированные таблицы. И поскольку это WordPress, я не могу изменять запросы в основном коде.

Но сколько я должен увеличить переменные, такие как query_cache_size и innodb_buffer_pool_size? Как насчет других переменных innodb?

Некоторые из предложенных переменных не существуют в my.cnf, например table_cache, и помечены в отчете о тюнере и т.д. Могу ли я добавить их в my.cnf?

(И почему этот блок дублируется в my.cnf? Могу ли я удалить дубликат?)

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

Ниже приведен файл my.cnf и вывод mysqltuner:

Содержание my.cnf:

query-cache-type = 1
query-cache-size = 8M

set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql

old_passwords=1

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

Вывод mysqltuner:

------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.45
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 133M (Tables: 637)
[--] Data in InnoDB tables: 10M (Tables: 344)
[--] Data in MEMORY tables: 126K (Tables: 2)
[!!] Total fragmented tables: 69

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 6h 24m 13s (2M q [22.135 qps], 116K conn, TX: 4B, RX: 530M)
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 35.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 303.7M (8% of installed RAM)
[OK] Slow queries: 0% (4/2M)
[OK] Highest usage of available connections: 53% (53/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/46.1M
[OK] Key buffer hit rate: 99.6% (749M cached / 2M reads)
[OK] Query cache efficiency: 32.2% (685K cached / 2M selects)
[!!] Query cache prunes per day: 948863
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 660K sorts)
[!!] Temporary tables created on disk: 46% (400K on disk / 869K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 24K opened)
[OK] Open file limit used: 10% (109/1K)
[OK] Table locks acquired immediately: 99% (2M immediate / 2M locks)
[!!] InnoDB data size / buffer pool: 10.6M/2.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)
    innodb_buffer_pool_size (>= 10M)

ОТВЕТЫ

Ответ 1

Я постараюсь помочь здесь. Отчет MysqlTuner подразумевает, что в этом VPS есть 4 ГБ ОЗУ, поэтому мои предложения основаны на этом.

query_cache_size. Это объем оперативной памяти MySQL, который можно использовать для кэширования результатов запросов к базе данных. Результаты, хранящиеся в кеше запросов, возвращаются намного быстрее, чем обычные, поэтому эта переменная может значительно ускорить процесс (более того, чем любые другие предлагаемые изменения).

Точно, какое правильное значение для вас займет какое-то экспериментирование. В настоящее время этот параметр установлен на 8M. Если в этом ящике имеется 4 ГБ ОЗУ, я бы начал с 64M, увеличившись до 128M, а затем 256M, если потребуется. После каждого изменения оставляйте вещи на несколько дней, а затем снова запустите MysqlTuner и сравните процент для "эффективности кеш-кекса" с тем, что было раньше. Для сервера, в основном использующего 5 блогов Wordpress, я сомневаюсь, что вы увидите улучшение выше 256M, и я бы не рекомендовал выходить за рамки восьмой вашей общей RAM.

Лично я считаю, что Munin (бесплатный инструмент мониторинга сервера) достаточно удобен для наблюдения за такими вещами. Например. здесь график MySQL из одного из моих полей:

График Munin MySQL http://tim.incutio.com/mysql-queries.png

Светло-зеленая область показывает, что обычный MySQL выбирает попадание в базу данных. Розовая область показывает выборки, обслуживаемые кешем, поэтому розовый = хороший.

tmp_table_size - для некоторых сложных запросов (особенно тех, которые используют GROUP BY или сложную сортировку) MySQL должен сначала создать временную таблицу, содержащую данные, а затем выполнить некоторые операции над ней, чтобы создать результат набор. Он попытается создать эти временные таблицы в памяти, поскольку это намного быстрее, чем создание их на диске; но для больших наборов результатов это не всегда возможно. tmp_table_size контролирует этот порог.

Я не могу представить, чтобы Wordpress выполнял чрезвычайно сложные запросы, поэтому я бы не стал за бортом с этим. MysqlTuner предлагает значение больше 32 МБ, поэтому начните с 64M и посмотрите, как это влияет на значение "Временные таблицы, созданные на диске" через несколько дней. Установите max_heap_table_size, пока вы на нем, как это предлагает.

thread_cache_size - Wordpress не использует постоянные подключения по умолчанию (это хорошо), поэтому каждый запрос создает новое соединение с вашей базой данных, а затем закрывает его, как только страница была сгенерирована. Эти накладные расходы незначительны, но использование thread_cache_size позволяет MySQL повторно использовать эти потоки соединений, которые помогут немного.

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

table_cache. Я немного туманна в этом вопросе, он, похоже, относится к кешу MySQL структуры таблицы. Я бы пошел с 128 для этого.

innodb_buffer_pool_size - это объем памяти, который MySQL может использовать для кэширования индексов и данных для таблиц InnoDB. Это немного меня озадачивает, так как я не думаю, что Wordpress использует InnoDB вообще - у вас есть и другие сайты на этом сервере?

Чтобы ответить на ваши другие вопросы, конфигурация после [mysqld_safe] применяется только к демону MySQL в безопасном режиме, а не к MySQL в целом, так что некоторые из переменных дублируются. Если вы измените innodb_buffer_pool_size, вы захотите изменить первый. Переменные не в файле, который вы можете добавить, да, но добавьте их над блоком [mysqld_safe] по той же причине.

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

Ответ 2

Есть больше инструментов для настройки базы данных mysql: http://www.day32.com/MySQL/ и http://www.maatkit.org/doc/ и http://hackmysql.com/mysqlsla

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

Вы можете вставить самые медленные запросы из результатов mysqla в текстовый файл и выполнить их с помощью maatkit.

mk-visual-explain –host hostname –user username –password passwort –database \
databasename -c query1.sql >> query1_data.txt

-

mk-query-profiler –host hostname –user username –password passwort –database \
databasename query1_data.txt >> query1_data.txt

Часто использование новой версии mysql имеет решающее значение для производительности. Я испытал, что планы выполнения сложных запросов очень разные, когда вы сравниваете, например, mysql 5.0.23 - 5.1.4. Они выполняются в нашей среде гораздо быстрее с 5.1.4.

Много полезной информации о mysql можно найти на http://www.mysqlperformanceblog.com/ и в книге "Высокопроизводительная MySQL".

Табельный кэш: Согласно книге "Кэш таблицы хранит объекты, которые представляют таблицы. Каждый объект в кэше содержит связанный с ним файл .frm и другие данные в зависимости от механизма хранения таблиц.

Дизайн кэша таблиц немного ориентирован на MyISAM - это одна из областей, где разделение между сервером и механизмом хранения не является полностью чистым по историческим причинам. Кэш таблицы немного менее важен для InnoDB, потому что InnoDB не полагается на него для множества целей (например, для хранения дескрипторов файлов, для этой цели для этого есть своя версия кэша таблицы). Однако даже InnoDB извлекает выгоду из кэширования проанализированных файлов .frm. ".

Если вы повышаете кеш таблицы, могут быть ошибки с ограничением открытых файлов. Вам также необходимо увеличить переменную open_files_limit на сервере и, возможно, ограничение на открытые файлы операционной системы: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/.

Кэш потоков:

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

[!!] Временные таблицы, созданные на диске: 46% (400K на диске/всего 869K) Если tmp_table_size и max_heap_table_size еще не установлены, увеличьте их. Операции с дисками очень медленны по сравнению с операциями RAM. Использует ли Wordpress много столбцов blob/text? то вы не увидите больших преимуществ, потому что столбцы BLOB и Text не разрешены в таблицах памяти.

[OK] Наивысшее использование доступных подключений: 53% (53/100) Чтобы сохранить RAM, вы можете уменьшить допустимые максимальные соединения. С другой стороны, вы можете выходить из соединений в пиковые времена.

Использование кеша opcode для PHP - очень хорошая идея!

Ответ 3

Мои рекомендации по настройке MySQL для WP:

Таблицы базы данных должны периодически оптимизироваться (и при необходимости восстанавливаться) для оптимальной производительности.

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

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

Другой альтернативой является ручная оптимизация и ремонт вашей таблицы с помощью инструмента, такого как phpmyadmin.

Кэш запросов MySQL сохраняет результаты запросов в случае повторения запроса. Тем не менее, он знает только, как сохранить байтовый текст запросов, а не их скомпилированные версии, поэтому небольшие изменения в запросе создадут разные записи кэша. Включите это, если у вас нет уникальных идентификаторов в каждом запросе. Вы можете включить его, добавив следующее в /etc/my.cnf:

query_cache_type = 1
query_cache_size = 26214400

Ответ 4

Это не прямой ответ на ваш вопрос, но, по моему опыту, wordpress может быть очень хорошо оптимизирован с использованием кеширования на внешних серверах. Кроме того, в основном Wordpress, по-видимому, привязан к процессору на внешних компьютерах, а не в базе данных. (возможно, вам стоит дважды проверить, действительно ли вы оптимизируете узкое место).

Посмотрите, например, на "общий кеш w3". Использование его с APC должно быть самым простым подходом. Убедитесь, что вы посмотрите размер apc.shm_size (в php.ini) и коэффициент кэширования (некоторые утилиты info apc должны быть снабжены w3tc).

Я видел, что экземпляры wordpress работают плавно на одном сервере с этой настройкой и более чем 200 000 просмотров страниц в месяц.