Выяснилось почему раньше не было ошибки, потом что тюнер запускался с рута.
А что вы скажете на то что вместе с этой ошибкой тюнег выдает:
OK All users have password assigned
И как можно аргуметировать то что ранее этой ошибки тюнер не выдавал?
Z-Style добавил 15.11.2011 в 13:15
В данный момент не могу глянуть. Обязательно посмотрю сегодня чуть позже.
Вроде бы должен. И раньше такой ошибки не было.
Единственно что менялось в мускуле это увеличивался параметр table_cache
Здесь имя_пользователя_БД - пользователь, созданный в mySQL менеджере для подключения сайта к БД. Сайт на WP.
Это похоже на SQL- инъекцию?
Z-Style добавил 10.11.2011 в 17:08
Спасибо. Видимо не понял намек.
Z-Style добавил 11.11.2011 в 17:07
Вот как бывает: меняли сервер, настраивали, ломали голову почему сервер в 3 раза мощнее а проблема не исчезает. А проблема по всей видимости оказалась в UA-IX который сейчас периодически глючит из-за большой нагрузки, созданной благодаря файловому мега-ресурсу ех.ua
Либо долго проходят пакеты либо вообще теряются. От сюда и проблемы с работоспособностью ресурса.
Прочел половину, либо вода либо не хватает знаний английского у меня.
Просто и так увеличил с 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)
Как тогда бороться с этим: Table cache hit rate: 1% ?
Превратили топик в личные дебаты.
Но и на том спасибо))
Изменил table_cache на 1024 но Opened_tables не уменьшается, = 313
Когда table_cache был 256 - Opened_tables даже меньше был.
Не понимаю.
