我在云 Linux（Ubuntu）服务器上的 Tomcat 上运行了一个 GWT 应用程序，最近我发布了该应用程序的新版本，突然我的服务器响应时间从平均 500 毫秒缩短到平均 15 秒。我运行了我所知道的所有监控工具。
- iostat 说我的磁盘利用率为 0.03%
- mysqltuner.pl 说我没问题，其他的请参见下文
- top 说我的处理器空闲率为 99%，平均负载为：0.20、0.31、0.33
- 内存使用率为 50% (-/+ 缓冲区/缓存：3997 3974)
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)
答案1
如果有人感兴趣的话，问题在于我们在某些时候超出了连接池中的最大连接数，这会导致线程等待池中的连接时产生滚雪球效应。这解释了为什么机器处于“睡眠”状态，所有东西都在队列中等待连接可用。