Периодически выдает ошибку соединения с БД ((

Ага, нашел))

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

Z-Style добавил 08.11.2011 в 20:30

mysqltuner на новом сервере:

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

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

[--] Data in MyISAM tables: 81M (Tables: 30)

[!!] InnoDB is enabled but isn't being used

[!!] Total fragmented tables: 3

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

[--] Up for: 19h 1m 33s (30M q [438.654 qps], 620K conn, TX: 159B, RX: 3B)

[--] Reads / Writes: 99% / 1%

[--] Total buffers: 64.0M global + 1.6M per thread (400 max threads)

[OK] Maximum possible memory usage: 710.9M (1% of installed RAM)

[OK] Slow queries: 0% (0/30M)

[OK] Highest usage of available connections: 29% (117/400)

[OK] Key buffer size / total MyISAM indexes: 6.0M/45.1M

[OK] Key buffer hit rate: 98.9% (750M cached / 7M reads)

[OK] Query cache efficiency: 59.2% (16M cached / 27M selects)

[!!] Query cache prunes per day: 6879993

[OK] Sorts requiring temporary tables: 0% (13 temp sorts / 1M sorts)

[!!] Temporary tables created on disk: 49% (441K on disk / 884K total)

[OK] Thread cache hit rate: 97% (14K created / 620K connections)

[!!] Table cache hit rate: 1% (31 open / 3K opened)

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

[OK] Table locks acquired immediately: 99% (11M immediate / 11M locks)

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

General recommendations:

Add skip-innodb to MySQL configuration to disable InnoDB

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 (> 16M)

tmp_table_size (> 16M)

max_heap_table_size (> 16M)

table_cache (> 256)

Вот и хорошо. Теперь у Вас есть шанс исправить проблему в более приятной обстановке... Вы ведь понимаете, что проблема есть и никуда не делась?

Начните вот с этого, с кеширования. Можно попробовать для начала использовать рекоммендации mysqltuner.pl.

Затем разобраться с этим:

Если не получится избавиться от временных таблиц по объективным причинам - попробуйте использовать tmpfs для временных файлов mysql.

Да. Спасибо за подсказки, буду отстраивать.

Пока что возник вопрос: как правильно выставить параметр table_cache ?

тут вам должно хватить число таблиц*3.

Конкретно по этому параметру mysqltuner частенько такое выдает. Проблема в том, что он не может отличить действительное создание таблицы на диске от таблицы в памяти. А в самом mysql нет достоверных счетчиков для этого факта.

Так что повышайте без фанатизма : повысили и снова оценили mysqltuner. Если показатель не уменьшился или уменьшился несущественно - уже хватит.

ну можно и поднять key_buffer

Вообще, параметров-то много, но на порядки ускорить mysql изменением настроек обычно не получится. Сосредоточьтесь на других методиках лучше.

Вот сказал же - 42, а у вас не меньше 117. И nginx наверняка не стоит.

Не понимаю, зачем мне уменьшать max-connections, если ресурсы позволяют? Чтобы возникла ошибка "too many connections"?

nginx стоит.

Ну, вот именно это я и обозвал "объективными причинами". Рекоммендованный Вами mysql-tunning.sh, кстати, дает в этом отношение хорошее замечание:

Начать с того, что научиться читать:

Это, вообще говоря, универсальная рекоммендация для автоматических "настраивалок".

Чтобы память расходовать на более полезные вещи.

Запомните также, что то значение, которое Вы указали в max-connections - должно быть _осмысленным_. Не только из соображения "быть достаточно большим, чтобы энта ошибка меня не доставала": сервер должен работать в таком режиме и памяти должно хватить _всем_. И mysql, и апачу с php, и nginx, и всему-что-там-еще-у-вас-есть. Включая Вас c sshd, чтобы Вы могли прийти на сервер и вручную разобраться в обстановке.

Зато в разы, в данном случае, - запросто. Особенно, если пишут относительно мало.

Такие рекомендации видимо иногда действительно помогают: перечитал еще раз, понял))

Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.

Это работает для типичных сайтов. Не для тех, на которых скрипты выполняются долго по объективным причинам - например, скрипты качающие что-то из сети.

Ну в данном случае и замеров никаких не сделано. Не известно насколько точно поможет.

Тогда встречный вопрос: как правильно определить для себя параметр MaxClients? (сейчас выставлено 250)

Запросы и так станут в очередь. Единственное достоинство этого подхода _в среднестатистическом случае_ (хайлоад всякий пока не рассматриваем) - "тяжелые" процессы не висят впустую в памяти, занимаясь запихиванием контента "в трубу" до медленных клиентов. Именно эту роль берет на себя nginx, стоящий перед апачем. Естественно, вместо nginx может быть практически любой современный вебсервере, тотже апач с mod_proxy.

Ну какие тут еще замеры? WP - должно помочь. Сейчас явно кеш используется, мягко говоря - слабо.