Тюнинг MySQL

VM
На сайте с 23.09.2009
Offline
192
2213

Помогите поднастроить MySQL. Имею следующий конфиг.

[mysqld]

port = 3306

socket = /var/lib/mysql/mysql.sock

pid-file = /var/lib/mysql/mysql/mysqld.pid

tmpdir = /tmp

default-storage-engine=myisam

skip-innodb

skip-bdb

skip-name-resolve

low-priority-updates

skip-external-locking

skip-character-set-client-handshake

bind-address = 127.0.0.1

max_connections = 60

key_buffer_size = 95M

max_allowed_packet = 16M

table_open_cache = 4

sort_buffer_size=1M

read_rnd_buffer_size=1M

read_buffer_size = 512K

net_buffer_length = 16K

thread_stack = 128K

table_cache = 100

tmp_table_size=32M

max_heap_table_size=32M

thread_cache_size = 4

query_cache_limit = 1M

query_cache_size=32M

query_cache_type = 1

join_buffer_size=1M

log-slow-queries=/var/lib/mysql/slow.log

interactive_timeout=60

wait_timeout=60

long_query_time=5

Вот что выдает mysqltuner.pl после суток работы.

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

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.5.32-MariaDB-log

[OK] Operating on 32-bit architecture with less than 2GB RAM

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

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

[--] Data in MyISAM tables: 148M (Tables: 76)

[!!] Total fragmented tables: 1

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

[OK] All database users have passwords assigned

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

[--] Up for: 10h 23m 33s (423K q [11.327 qps], 62K conn, TX: 904M, RX: 62M)

[--] Reads / Writes: 62% / 38%

[--] Total buffers: 159.0M global + 3.6M per thread (60 max threads)

[OK] Maximum possible memory usage: 376.5M (36% of installed RAM)

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

[OK] Highest usage of available connections: 55% (33/60)

[OK] Key buffer size / total MyISAM indexes: 95.0M/93.4M

[OK] Key buffer hit rate: 100.0% (304M cached / 82K reads)

[OK] Query cache efficiency: 68.0% (170K cached / 250K selects)

[!!] Query cache prunes per day: 58154

[!!] Sorts requiring temporary tables: 19% (200 temp sorts / 1K sorts)

[!!] Temporary tables created on disk: 26% (159 on disk / 602 total)

[OK] Thread cache hit rate: 99% (379 created / 62K connections)

[!!] Table cache hit rate: 17% (100 open / 584 opened)

[OK] Open file limit used: 19% (203/1K)

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

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

General recommendations:

Run OPTIMIZE TABLE to defragment tables for better performance

MySQL started within last 24 hours - recommendations may be inaccurate

When making adjustments, make tmp_table_size/max_heap_table_size equal

Reduce your SELECT DISTINCT queries without LIMIT clauses

Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

query_cache_size (> 32M)

sort_buffer_size (> 1M)

read_rnd_buffer_size (> 1M)

tmp_table_size (> 32M)

max_heap_table_size (> 32M)

table_cache (> 100)

Как подобрать эти параметры, особенно интересно то что выделено крассным. На VDS крутится пару сайтов, в общем 15 000 хостов в день. Все работает гладко и вроде не глючит. Но данный тест не дает покоя.

N
На сайте с 06.05.2007
Offline
419
#1

vip-moto, сообщение Reduce your SELECT DISTINCT queries without LIMIT clauses относится к свойствам ваших запросов. Убрать его настройками нельзя.

Increase table_cache gradually to avoid file descriptor limits

А это можно убрать. Увеличьте table_cache больше 100. Толк обычно не заметен.

Кнопка вызова админа ()
P
На сайте с 16.03.2009
Offline
144
#2

table_cache -> 1024 (как минимум 600)

[!!] Table cache hit rate: 17% (100 open / 584 opened)

table_open_cache -> 1024

key_buffer_size -> 128M

thread_cache_size -> 16

query_cache_size -> 64M

Чтобы понять, какой параметр выставить для query_cache_size

ставьте munin и плагин для mysql query_cache_size

Так же наглядно, можно увидеть работу кеша

Здесь интересно посмотреть тесты по буферам(sort_buffer_size, read_rnd_buffer_size и т.д.) и вообще почитать

http://www.mysqlperformanceblog.com/

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#3

Можете почитать вот тут вот, ну или попробовать поиском воспользоваться по форуму.

Есть около 15.000 ipv4 !!! (http://onyx.net.ua/price.php#ipv4) Качественный хостинг с 2005 года - лучшее клиентам! (http://onyx.net.ua/)
VM
На сайте с 23.09.2009
Offline
192
#4
poiuty:
table_cache -> 1024 (как минимум 600)


table_open_cache -> 1024
key_buffer_size -> 128M
thread_cache_size -> 16
query_cache_size -> 64M


Чтобы понять, какой параметр выставить для query_cache_size
ставьте munin и плагин для mysql query_cache_size


Так же наглядно, можно увидеть работу кеша


Здесь интересно посмотреть тесты по буферам(sort_buffer_size, read_rnd_buffer_size и т.д.) и вообще почитать
http://www.mysqlperformanceblog.com/

А как работать с этими плагинами есть инструкция на русском?

и еще вопрос по поводу таймаутов

interactive_timeout=60

wait_timeout=60

Хватит или еще уменьшить? Как вообще они влияют

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#5
vip-moto:
А как работать с этими плагинами есть инструкция на русском?

и еще вопрос по поводу таймаутов
interactive_timeout=60
wait_timeout=60

Хватит или еще уменьшить? Как вообще они влияют

Если не ошибаюсь то:

wait_timeout - Ожидание активности от любого клиента перед тем как разорвать соединение. Если клиент будет интерактивный и значение interactive_timeout отличается от wait_timeout, то будет использовано значение interactive_timeout.

VM
На сайте с 23.09.2009
Offline
192
#6
Romka_Kharkov:
Если не ошибаюсь то:
wait_timeout - Ожидание активности от любого клиента перед тем как разорвать соединение. Если клиент будет интерактивный и значение interactive_timeout отличается от wait_timeout, то будет использовано значение interactive_timeout.

а каких приделов придерживаться?

Glueon
На сайте с 26.07.2013
Offline
172
#7
vip-moto:
а каких приделов придерживаться?

Зависит от вашего приложения. Если между запросами, либо между подключением к MySQL серверу и запросом непосредственно, выполняется длинный код - лучше ставить побольше. На на практике, по-моему, даже ниже 60 можно опуститься. Не cron'овский PHP скрипт, который висит дольше 15 секунд - это уже не очень здорово. Можете поставить, поэтому, и 30, но не совсем видна выгода в этом.

Есть много IP-сетей в аренду под прокси, парсинг, рассылки (optin), vpn и хостинг. Телега: @contactroot ⚒ ContactRoot команда опытных сисадминов (/ru/forum/861038), свой LIR: сдаем в аренду сети IPv4/v6 (/ru/forum/1012475).
N
На сайте с 06.05.2007
Offline
419
#8
vip-moto:
Все работает гладко и вроде не глючит. Но данный тест не дает покоя.
vip-moto:
А как работать с этими плагинами есть инструкция на русском?

есть на английском, но широко используется в школьном образовании в России: Don't trouble trouble until trouble troubles you.

Реально результативная оптимизация mysql делается не так.

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#9
vip-moto:
а каких приделов придерживаться?

Верно написали, все индивидуально....

Недавно приходил ко мне клиент, с ошибкой mysql gone away....

Сперва подумал сервер перегружен, начал изучать, все в полной норме как и показывал мониторинг.... пришли к приложению и выяснили что у человека сперва открывается sql сессия, потом начинает генерится какой-то контент а после этого пытается писаться в базу.... так вот от момента открытия до записи за счет генерации проходило более 30 sec которые установлены у меня, решение было следующим: в скриптах человек начал открывать соединение с SQL по факту формирования необходимых данных для инсерта, ошибка как понимаете пропала... а поменялась только логика скрипта :D

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий