昨天为一位拥有高负载服务器的客户开了一个关于Haproxy故障排除的有趣会议。Haproxy是一个非常高性能的系统,可达每秒10万次的请求,10万个连接,而且非常灵活,我们无处不在使用它(而且这这方面远优于nginx或者是LVS)。运行每天有数亿的请求这样如此大规模的连接水平的系统来说是非常困难的,即使有专门的Linux内核调优,以及仔细的监测和管理。
问题是在150-200,000并发连接,但低于每秒5000请求,系统变得很慢,需要几秒钟响应。在标准故障排除,如检查整体CPU,内存,sockets,内核消息,iptables连接跟踪限制的TCP内存和压力,这种情况下发现不了什么奇怪的现象。由于这是一个虚拟机,我们也检查底层的Xen dom0的系统因为CPU有其他限制,也影响虚拟机的负载性能。
但是查看每个进程的CPU使用,显示Haproxy使用大于95%的CPU资源,这是进程使用CPU超负荷的一个明显标志。Haproxy通常是一个单独的进程事件驱动系统(Nginx它具有相同的架构),这是它如何达到如此高的性能的原因。但如果单个的进程的负载比单个CPU可以处理的更多,那系统便崩溃了,或者至少是变的非常缓慢。但实际上,我惊讶的是100%的系统完全可以运作,而且仍然在3-5,000请求/秒和20万个连接。
为什么CPU负载过高?我们不能马上下定论,因为实际的请求率并不高。但我们认为原因在于连接的数量和管理该名单的开销上,即使在理论上内核应该使用epoll()去处理,但是系统方面的cpu相当的高,也许是所有socket选择的工作所致。
问题是在150-200,000并发连接,但低于每秒5000请求,系统变得很慢,需要几秒钟响应。在标准故障排除,如检查整体CPU,内存,sockets,内核消息,iptables连接跟踪限制的TCP内存和压力,这种情况下发现不了什么奇怪的现象。由于这是一个虚拟机,我们也检查底层的Xen dom0的系统因为CPU有其他限制,也影响虚拟机的负载性能。
但是查看每个进程的CPU使用,显示Haproxy使用大于95%的CPU资源,这是进程使用CPU超负荷的一个明显标志。Haproxy通常是一个单独的进程事件驱动系统(Nginx它具有相同的架构),这是它如何达到如此高的性能的原因。但如果单个的进程的负载比单个CPU可以处理的更多,那系统便崩溃了,或者至少是变的非常缓慢。但实际上,我惊讶的是100%的系统完全可以运作,而且仍然在3-5,000请求/秒和20万个连接。
为什么CPU负载过高?我们不能马上下定论,因为实际的请求率并不高。但我们认为原因在于连接的数量和管理该名单的开销上,即使在理论上内核应该使用epoll()去处理,但是系统方面的cpu相当的高,也许是所有socket选择的工作所致。