myhand: Причем тут "метод тыка"? Смотрим на статистику (достаточно посмотреть top на обычное число процессов апача или на информацию mod_status) - и выставляем лимиты в соответствии с ней. Все "строго научно" (тм), никакого тыка.
В периоды максимальной загрузки доходит до установленного максимума (250)
Кстати, а что означают процессы созданные от 127.0.0.1 ? (очень много таких) Это SpareServers?
И еще: если поток создан, он не удаляется а только занимает память?
netwind: Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.
Тогда встречный вопрос: как правильно определить для себя параметр MaxClients? (сейчас выставлено 250)
Но вот же незадача было разобраться с этой ошибкой: пока я добрался до сервера, его оказывается уже заменили более производительным, настройки же остались прежними, теперь ресурс не тормозит, но настраивать mysql я так понимаю еще нужно.
Причем тут "метод тыка"? Смотрим на статистику (достаточно посмотреть top на обычное число процессов апача или на информацию mod_status) - и выставляем лимиты в соответствии с ней. Все "строго научно" (тм), никакого тыка.
В периоды максимальной загрузки доходит до установленного максимума (250)
Кстати, а что означают процессы созданные от 127.0.0.1 ? (очень много таких) Это SpareServers?
И еще: если поток создан, он не удаляется а только занимает память?
начните с 10 :)
определяется объемом памяти доступной в системе и расчетами потребления ее на 1 запрос (1 Apache и 1 коннект к MySQL).
только из практики. например, делаем такой график http://ww.udaff.com/munin/localdomain/localhost.localdomain-apache_processes.html
и видим, что тут 10 хватает с запасом. единичные всплески munin выравняет.
То есть, maxClients определяем пока не будет достаточно, либо пока будет хватать памяти при условии что процессор не загнется (id=0)?
Идея в том чтобы уменьшить MaxClients, чтобы апачи попусту не плодились, а запросы становились в очередь. Каждый апач - это лишних 64-128 мб памяти отнятых у кеша ОС. Уменьшать max-connections в mysql не нужно.
Тогда встречный вопрос: как правильно определить для себя параметр MaxClients? (сейчас выставлено 250)
Начать с того, что научиться читать:
Такие рекомендации видимо иногда действительно помогают: перечитал еще раз, понял))
Вот сказал же - 42, а у вас не меньше 117. И nginx наверняка не стоит.
Не понимаю, зачем мне уменьшать max-connections, если ресурсы позволяют? Чтобы возникла ошибка "too many connections"?
nginx стоит.
Вы ведь понимаете, что проблема есть и никуда не делась?
Да. Спасибо за подсказки, буду отстраивать.
Пока что возник вопрос: как правильно выставить параметр table_cache ?
А посмотрите ман, ага?
Ага, нашел))
Но вот же незадача было разобраться с этой ошибкой: пока я добрался до сервера, его оказывается уже заменили более производительным, настройки же остались прежними, теперь ресурс не тормозит, но настраивать 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)
WP прекрасно кешируется на уровне nginx.
Вы говорите об обычном кешировании для WP с помощью плагинов или о чем-то другом?
Z-Style добавил 08.11.2011 в 19:46
А что это за параметр -q ?
Эту ошибку выдает wordpress при любой проблеме с БД.
Если хотите увидеть реальную ошибку, впишите define('WP_DEBUG', true); в wp-config.php
Таки да. Это вп. И спасибо за совет.
Спасибо за ссылку на скрипт. Пока не было времени протестить.