COntrollo MySQL

[Shork]

Ho un server con 150 siti, ogni tanto mysql porta la CPU al 70-80% e non riesco a capire quale operazione abbia portato a questo; controllando nelle slow query non ho visto cose particolarmente strane, quale altra strada posso seguire per aiutarmi a capire dov'è il problema?

Grazie

[kruskaiev]

Ho avuto dei problemi simili con dei DB Oracle anche in cluster. La maggior parte delle volte si è visto un problema lato switch dell'interconnect dei nodi del cluster che ne causava l'eviction del nodo con dei problemi.
Secondo me ti conviene controllare un po' di cose nel momento in cui avviene il picco di CPU.

• controlla lo stato della RAM e soprattutto quale processo occupa più RAM in quel momento
• controlla il numero di connessioni al DB, perché ogni connessione alloca un tot di ram, e quindi un eccesso di connessioni, potrebbero esaurirla
• controlla lo stato della rete pubblica e dell'interconnect (nel caso fosse un Cluster MySQL) o altri tipi di errori che puoi trovare nei messages o magari con ethtool
• controlla le query che vengono lanciate in quel momento, magari c'è un grosso update che blocca tutto quanto
• già che ci sei controlla i log di mysql che non fa mai male

[Shork]

Con TOP vedo che mysql mi occupa il 2%, ma la causa è lui perche riavviando il demone da un 70% si torna a 1%!

Nel message non ho nulla di particolare.

Per gli altri controlli ti chiederei qualche dritta

[detroit]

fai un pò di controlli con mysqltuner

[Shork]

Ecco il report:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.84-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 288M (Tables: 4733)
[--] Data in InnoDB tables: 4M (Tables: 232)
[!!] Total fragmented tables: 216

-------- Performance Metrics -------------------------------------------------
[--] Up for: 24m 48s (134K q [90.387 qps], 1K conn, TX: 54M, RX: 22M)
[--] Reads / Writes: 89% / 11%
[--] Total buffers: 152.0M global + 1.6M per thread (300 max threads)
[OK] Maximum possible memory usage: 639.5M (16% of installed RAM)
[OK] Slow queries: 0% (0/134K)
[OK] Highest usage of available connections: 7% (23/300)
[OK] Key buffer size / total MyISAM indexes: 16.0M/30.4M
[OK] Key buffer hit rate: 99.8% (738K cached / 1K reads)
[OK] Query cache efficiency: 83.8% (103K cached / 122K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[!!] Joins performed without indexes: 25
[OK] Temporary tables created on disk: 11% (382 on disk / 3K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 13% (512 open / 3K opened)
[OK] Open file limit used: 65% (988/1K)
[OK] Table locks acquired immediately: 100% (27K immediate / 27K locks)
[OK] InnoDB data size / buffer pool: 4.0M/32.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Adjust your join queries to always utilize indexes
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
join_buffer_size (> 128.0K, or always use indexes with joins)
thread_cache_size (start at 4)
table_cache (> 512)

[Shork]

Ho corretto i 3 valori che mi ha indicato... stiamo a vedere se cambia qualcosa... :-)

[detroit]

Originariamente inviato da Shork
Ho corretto i 3 valori che mi ha indicato... stiamo a vedere se cambia qualcosa... :-)

Fallo girare periodicamente tipo ogni 24h finchè non trovi i valori che ti vanno bene