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

а когда смотрел, то увидел там в пакете установочный скрипт, который берет и копирует файл php.ini-production, в котором указано 128 мб. чето как то не так вы смотрите.

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

у нас на серверах table_cache, и table_definition_cache - несколько десятков тысяч.

Главное еще понять - куда копирует. Не верите/не в стостоянии разобраться - поставьте пакет и посмотрите.

Оффтопик, однако.

вот вы и поставьте.

оффтопик бывает только в форуме платной технической поддержки.

а тут форум для всех.

Как тогда бороться с этим: Table cache hit rate: 1% ?

Увеличивайте table_cache. Подробно - я же давал Вам ссылку. Вы прочли?

Прочел половину, либо вода либо не хватает знаний английского у меня.

Просто и так увеличил с 256 на 1024...

Вот лог тюнера сейчас:

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

[--] Up for: 13h 22m 12s (15M q [312.332 qps], 314K conn, TX: 67B, RX: 1B)

[--] 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% (1/15M)

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

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

[OK] Key buffer hit rate: 99.6% (86M cached / 358K reads)

[OK] Query cache efficiency: 75.1% (10M cached / 13M selects)

[OK] Query cache prunes per day: 0

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

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

[OK] Thread cache hit rate: 98% (3K created / 314K connections)

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

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

[OK] Table locks acquired immediately: 99% (2M immediate / 2M 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 (> 1024)

У тебя гадание вместо статистики идет.

Есть такое подозрение. Ибо нам пишут - а мы не читаем, в частности:

Ну и Вам достаточно прозрачно люди уже намекнули, что 1k в table_cache - мало. Тем более, если у Вас не самописный скрипт с парой таблиц в базе, а всякие вордпрессы.

Z-Style добавил 10.11.2011 в 17:08

Спасибо. Видимо не понял намек.

Z-Style добавил 11.11.2011 в 17:07

Вот как бывает: меняли сервер, настраивали, ломали голову почему сервер в 3 раза мощнее а проблема не исчезает. А проблема по всей видимости оказалась в UA-IX который сейчас периодически глючит из-за большой нагрузки, созданной благодаря файловому мега-ресурсу ех.ua

Либо долго проходят пакеты либо вообще теряются. От сюда и проблемы с работоспособностью ресурса.