Desaceleração do servidor

Question

Eu tenho um aplicativo GWT rodando no Tomcat em um servidor cloud linux (Ubuntu), recentemente eu lancei uma nova versão do aplicativo e de repente meus tempos de resposta do servidor passaram de uma média de 500ms para uma média de 15s. Eu corri todas as ferramentas de monitoramento que eu conheço.

• iostat diz que meus discos são 0,03% utilizados
• mysqltuner.pl diz que eu sou OK outro veja abaixo
• top diz que meu processador está 99% inativo e média de carga: 0,20, 0,31, 0,33
• uso de memória é de 50% (- / + buffers / cache: 3997 3974)

saída do mysqltuner

[OK] Logged in using credentials from debian maintenance account.

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.63-0ubuntu0.10.04.1-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 370M (Tables: 52)
[--] Data in InnoDB tables: 697M (Tables: 1749)
[!!] Total fragmented tables: 1754

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 19h 25m 41s (1M q [28.122 qps], 1K conn, TX: 2B, RX: 1B)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 1.0G global + 2.7M per thread (500 max threads)
[OK] Maximum possible memory usage: 2.4G (30% of installed RAM)
[OK] Slow queries: 0% (1/1M)
[OK] Highest usage of available connections: 34% (173/500)
[OK] Key buffer size / total MyISAM indexes: 16.0M/279.0K
[OK] Key buffer hit rate: 99.9% (50K cached / 40 reads)
[OK] Query cache efficiency: 61.4% (844K cached / 1M selects)
[!!] Query cache prunes per day: 553779
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 34K sorts)
[OK] Temporary tables created on disk: 4% (4K on disk / 102K total)
[OK] Thread cache hit rate: 84% (185 created / 1K connections)
[!!] Table cache hit rate: 0% (256 open / 27K opened)
[OK] Open file limit used: 0% (20/2K)
[OK] Table locks acquired immediately: 100% (692K immediate / 692K locks)
[OK] InnoDB data size / buffer pool: 697.2M/1.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 16M)
    table_cache (> 256)

    

Answer 1

Se alguém estiver interessado, o problema é que em algum momento ultrapassamos o número máximo de conexões no pool de conexões que causou um efeito de bola de neve nos threads aguardados por uma conexão do pool. Isso explica por que a máquina estava "adormecida", tudo estava esperando em uma fila para que uma conexão ficasse disponível.