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

Новый уже в любом случае необходим.

Z-Style добавил 09.11.2011 в 21:12

Новый сервер 2х Xeon 2.67, 48Gb

Старые настройки MySQL:

query_cache_size 16M

tmp_table_size 16M

max_heap_table_size 16M

table_cache 256

key_buffer_size 6М

Сайт в принципе работал нормально.

По логам скула не хватает кеша, не хватает индексов.

Рекомендации тюнера:

-------- 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)

Изменил параметры:

query_cache_size 256

tmp_table_size 256

max_heap_table_size 256

table_cache 512

После изменения настроек сайт бывает притормаживает.

Процессор работает на все 100%, идлов 0

Свободной памяти 38Гб (занято 10)

Задержек от дисковой подсистемы нет.

Created_tmp_disk_tables растет по прежднему.

Opened_tables стало еще больше.

Table_locks_waited стало больше.

Рекомендации тюнера теперь:

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

[--] Up for: 1h 14m 12s (4M q [1K qps], 97K conn, TX: 24B, RX: 617M)

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

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

[OK] Maximum possible memory usage: 1006.3M (2% of installed RAM)

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

[OK] Highest usage of available connections: 9% (23/250)

[OK] Key buffer size / total MyISAM indexes: 64.0M/45.6M

[OK] Key buffer hit rate: 99.7% (34M cached / 103K reads)

[OK] Query cache efficiency: 76.7% (3M cached / 4M selects)

[OK] Query cache prunes per day: 0

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

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

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

[!!] Table cache hit rate: 9% (29 open / 299 opened)

[OK] Open file limit used: 3% (41/1K)

[OK] Table locks acquired immediately: 99% (880K immediate / 880K 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

Temporary table size is already large - reduce result set size

Reduce your SELECT DISTINCT queries without LIMIT clauses

Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

table_cache (> 512)

Что делать пока не знаю.

Нет самого простого способа "сделать зашибись" (тм). Есть конкретная задача - будут и конкретные решения.

В частности, разрешить изменение memory_limit. Или вообще запускать скрипт иначе, например с другим SAPI.

Проблема дистрибутива с такими "дефолтами", нет?

Вот и увеличьте эту переменную. При необходимости - еще и лимит на число дескрипторов (как уже разбирали ранее).

С временными таблицами, возможно, уже ничего не выйдет. Попробуйте поместить раздел для временных файлов mysql (не весь /tmp !) - на tmpfs.

про что вам я и толкую :

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

и какие ж такие данные об этом свидетельствуют ?

netwind добавил 09.11.2011 в 21:25

противоречит требованиям безопасности и управляемости сервера.

это в самом php так.

Сделал поспешный, возможно неправильный вывод. Но суть в том что притормаживание бывает. Возможно конечно и не в скуле причина.

Z-Style добавил 09.11.2011 в 21:29

Ок. Число дескрипторов установлено unlimited.

так начните наконец делать правильные выводы исходя из результатов исследования всего сервера как комплекса программ. чего вы к этому mysql прикопались не понятно.

81 мб данных это не смешно даже.

Это откуда цифра?

Вы путаете ужа с ежом: memory_limit отродясь средством обеспечения безопасности и управляемости не был. Это средство типа зарока пьяницы в клубе анонимных алкоголиков: "мы выставили здеся лимит в X Mb и потому обязуемся не использовать энтими вот скриптами памяти больше чем подписались...". В итоге, всегда есть вероятность что программист опрокинет стакашкувыставит позже безумный memory_limit.

А реальные ограничения - это rlimit. Они тоже могут быть разными, даже для одного пользователя - например, для веб-скриптов и в консоли (крон).

Это те, что в примере php.ini, идущего с исходниками? Ну так это _пример_.

Типа крута?

Стояло по умолчанию. Плохо?

Z-Style добавил 09.11.2011 в 21:55

Далее tmp_table_size уже не увеличивать?

Плохо, конечно.

Это какой-же дистрибутив такое счастье устраивает?

Вам даже скрипт об этом написал. Очевидно - нет, это не дает эффекта. Почему такое может быть - объясняли выше.

ТС, а не пробовали mysql_pconnect протестировать, вместо mysql_connect