我们有一个虚拟化的LAMP + memcached + nginx设置，经过几个月前的一些调整后，直到最近（3-4个星期前）才performance良好。
在高峰时间，服务器变得几乎无法访问，通常与nginx给500 – 尽pipe我原来的评估似乎没有超时相关，因为这经常发生在一两秒钟内。 看看我们的munin图，MySQL似乎是罪魁祸首，但我不明白为什么。
在此之前，每秒查询次数会像预期的那样在高峰时间上升，最终达到一个可控的高峰，并在几小时后消失。 现在，尽pipe峰值并不比以前高，但是一旦峰值达到峰值，性能坦克就会出现，如吞吐量和查询/秒指标所反映的那样。
CPU至less有50％空闲，有几个内存仍未使用，并且没有交换或I / O争用。 缓慢的MySQL查询以每秒0.01-0.02的速度上升，并且很less有超过15个线程同时运行。 我注意到的一件事情是，与这些情节中的每一个相对应的MySQL磁盘写入略微（2-4K块/秒）的增加，尽pipe我不能直接看到连接是什么，但我必须相信这是相关的。
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万用户logging和相关数据，其中每天访问约150万，每月约130万。
任何意见如何进行表示赞赏。
附录：看起来nginx通常是以“24：太多打开的文件”失败的，包括试图与Apache交谈的时候。 ulimit说nginx的文件句柄限制是1024 – 这是不是太less？
附录2 /答案：好吧，尴尬，我find了我自己的问题的答案，这与上面的附录有关。
Nginx的同时打开的文件句柄的限制设置为1024.因此，许多向Apache发出的请求从未交付，导致MySQL吞吐量自然下降 – 这不是因为MySQLperformance不佳，而是因为有这么多的请求做了这么多。 这并不能解释磁盘活动的增加，但可能在问题出现之前，这种活动总是存在 – 可悲的是，性能图不能回到那么远。
无论如何，我加了“worker_rlimit_nofile 2048” 到nginx.conf，它覆盖了ulimit认为最大的文件句柄，性能已经恢复。 如果有人遇到这个问题，那么这就是答案。 ;）
（为了logging，我不能/实际上/回答我自己的问题，因为这个问题太新了。）