技术故障排除 - HAProxy 性能和负载

本文讲述了在处理高并发连接时,HAProxy出现性能下降的问题。通过深入排查,发现原因是大量并发连接导致的CPU占用过高。通过缩短TCP保持存活时间和启用多进程功能,成功缓解了系统延迟,并提升了服务器的承载能力。总结了处理大型网站和负载均衡系统的运维经验。
摘要由CSDN通过智能技术生成
昨天为一位拥有高负载服务器的客户开了一个关于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选择的工作所致。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值