昨天为一位拥有高负载服务器的客户开了一个关于 Haproxy故障排除的有趣会议。Haproxy是一个非常高性能的系统&＃xff0c;可达每秒10万次的请求&＃xff0c;10万个连接&＃xff0c;而且非常灵活&＃xff0c;我们无处不在使用它 &＃xff08;而且这这方面远优于nginx或者是LVS&＃xff09;。运行每天有数亿的请求这样如此大规模的连接水平的系统来说是非常困难的&＃xff0c;即使有专门的Linux内核调 优&＃xff0c;以及仔细的监测和管理。

问题是在150-200,000并发连接&＃xff0c;但低于每秒5000请求&＃xff0c;系统变得很慢&＃xff0c;需要几秒钟响应。在标准故 障排除&＃xff0c;如检查整体CPU&＃xff0c;内存&＃xff0c;sockets&＃xff0c;内核消息&＃xff0c;iptables连接跟踪限制的TCP内存和压力&＃xff0c;这种情况下发现不了什么奇怪的现象。由于 这是一个虚拟机&＃xff0c;我们也检查底层的Xen dom0的系统因为CPU有其他限制&＃xff0c;也影响虚拟机的负载性能。

但是查看每个进程的CPU使 用&＃xff0c;显示Haproxy使用大于95&＃xff05;的CPU资源&＃xff0c;这是进程使用CPU超负荷的一个明显标志。Haproxy通常是一个单独的进程事件驱动系统 &＃xff08;Nginx它具有相同的架构&＃xff09;&＃xff0c;这是它如何达到如此高的性能的原因。但如果单个的进程的负载比单个CPU可以处理的更多&＃xff0c;那系统便崩溃了&＃xff0c;或者至少是变 的非常缓慢。但实际上&＃xff0c;我惊讶的是100&＃xff05;的系统完全可以运作&＃xff0c;而且仍然在3-5,000请求/秒和20万个连接。

为什么CPU负载过高&＃xff1f;我们不能马上下定论&＃xff0c;因为实际的请求率并不高。但我们认为原因在于连接的数量和管理该名单的开销上&＃xff0c;即使在理论上内核应该使用epoll()去处理,但是系统方面的cpu相当的高&＃xff0c;也许是所有socket选择的工作所致。

有 一个问题&＃xff0c;为什么许多连接和回答都是长TCP保持存活时间&＃xff0c;默认是2分钟的保持时间。所以每秒2000个新连接和超过100秒的平均连接时间导致了 20万的连接数&＃xff0c;就这么简单。我们采取缩短超时&＃xff0c;这通常会降低用户体验&＃xff0c;但对于这个应用来说不是很至关重要的&＃xff0c;所以安全起见&＃xff0c;我们调整到60秒或者更低&＃xff0c; 比如15秒或者必要时所幸关闭存活时间来调优。&＃xff08;因为对于这个客户来说&＃xff0c;我们只看到每秒1.2个的请求连接&＃xff0c;比一般典型的网站要少的多&＃xff09;。

如 今的整体解决方案是启用Haproxy的多进程功能&＃xff0c;这是一个使用起来很复杂的功能&＃xff0c;因为统计和监控每个进程是随机在它们之间切换的&＃xff0c;所以调试和监控数据 就变的没有什么很大的作用了。但是每个进程的cpu使用会降致50&＃xff05;而且服务器很容易就能承受12万的连接数。我们将以这种方式运行一段时间看看效果如 何&＃xff0c;还有我们为了更好的监控也会恢复到单进程模式&＃xff0c;除非找到一个更好的方法去解决监控每个进程方法。

总的来说&＃xff0c;这就是我一天的工作&＃xff0c;
管理大型网站和高性能的负载均衡系统以及运维高端技术。以此同时&＃xff0c;我们还是需要每天学习更新的知识&＃xff0c;庆幸的是&＃xff0c;我们可以通过我们的客户平台和你分享这些知识。