我们有一个虚拟化的 LAMP+memcached+nginx 设置，经过几个月前的一些调整后，直到最近（3-4 周前）一直表现良好。
在高峰时段，服务器几乎无法访问，通常 nginx 会给出 500 错误——尽管我最初的评估似乎与超时无关，因为这通常在一两秒内发生。查看我们的 munin 图表，MySQL 似乎是罪魁祸首，但我不明白具体原因。
在此之前，每秒查询数会在高峰期按预期上升，最终达到可控的峰值并在几个小时后下降。现在，尽管峰值没有比以前更高，但一旦达到峰值，性能就会下降，这可以从吞吐量和每秒查询数指标中反映出来。
CPU 至少有 50% 处于空闲状态，还有几 GB 的内存未使用，并且不存在交换或 I/O 争用。慢速 MySQL 查询最高约为每秒 0.01-0.02 个，并且同时运行的线程很少超过 15 个。我注意到的一件事是，在每次发生这些事件的同时，MySQL 磁盘的写入量略有增加（2-4K 块/秒），我不得不相信这是相关的，尽管我无法直接看出其中的联系。
mysqltuner 建议了一些与内存相关的更改，主要如下：
query_cache_limit (> 4M, or use smaller result sets)
sort_buffer_size (> 32M)
read_rnd_buffer_size (> 32M)
innodb_buffer_pool_size (>= 9G)
我无法评估这些变化可能产生的影响（如果有的话），或者主要问题是什么，因为我没有发现明显的争议。数据库的主要内容是约 1000 万条用户记录和相关数据，其中每天访问约 15 万条，每月访问约 130 万条。
如能得到关于如何进行的任何建议，我们将不胜感激。
附录：看来 nginx 经常出现“24：打开的文件太多”的故障，包括在尝试与 Apache 通信时。ulimit 说 nginx 的文件句柄限制是 1024——这太少了吗？
附录 2/答案：好吧，虽然可能令人尴尬，但我找到了我自己问题的答案，它与上面的附录有关。
Nginx 达到了同时打开文件句柄数的上限，该上限被设置为 1024。结果，许多发往 Apache 的请求从未被传递，这导致 MySQL 吞吐量自然下降——不是因为 MySQL 性能不佳，而是因为到达这个上限的请求越来越少。这并不能完全解释磁盘活动增加的原因，但可能这种活动在问题出现之前就一直存在——遗憾的是，性能图表没有回溯到那么远。
无论如何，我在 nginx.conf 中添加了“worker_rlimit_nofile 2048;”，这将覆盖 ulimit 对最大文件句柄的考虑，并且性能已恢复。如果其他人遇到这个问题，那么，这就是答案。;)
（据记录，我实际上无法回答我自己的问题，因为这个问题太新了。）