技术故障排除 - HAProxy 性能和负载
来源:互联网 发布:golang beego安装 编辑:程序博客网 时间:2024/05/21 15:43
昨天为一位拥有高负载服务器的客户开了一个关于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选择的工作所致。
有一个问题,为什么许多连接和回答都是长TCP保持存活时间,默认是2分钟的保持时间。所以每秒2000个新连接和超过100秒的平均连接时间导致了 20万的连接数,就这么简单。我们采取缩短超时,这通常会降低用户体验,但对于这个应用来说不是很至关重要的,所以安全起见,我们调整到60秒或者更低,比如15秒或者必要时所幸关闭存活时间来调优。(因为对于这个客户来说,我们只看到每秒1.2个的请求连接,比一般典型的网站要少的多)。
如今的整体解决方案是启用Haproxy的多进程功能,这是一个使用起来很复杂的功能,因为统计和监控每个进程是随机在它们之间切换的,所以调试和监控数据就变的没有什么很大的作用了。但是每个进程的cpu使用会降致50%而且服务器很容易就能承受12万的连接数。我们将以这种方式运行一段时间看看效果如何,还有我们为了更好的监控也会恢复到单进程模式,除非找到一个更好的方法去解决监控每个进程方法。
总的来说,这就是我一天的工作,
管理大型网站和高性能的负载均衡系统以及运维高端技术。以此同时,我们还是需要每天学习更新的知识,庆幸的是,我们可以通过我们的客户平台和你分享这些知识。
问题是在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选择的工作所致。
有一个问题,为什么许多连接和回答都是长TCP保持存活时间,默认是2分钟的保持时间。所以每秒2000个新连接和超过100秒的平均连接时间导致了 20万的连接数,就这么简单。我们采取缩短超时,这通常会降低用户体验,但对于这个应用来说不是很至关重要的,所以安全起见,我们调整到60秒或者更低,比如15秒或者必要时所幸关闭存活时间来调优。(因为对于这个客户来说,我们只看到每秒1.2个的请求连接,比一般典型的网站要少的多)。
如今的整体解决方案是启用Haproxy的多进程功能,这是一个使用起来很复杂的功能,因为统计和监控每个进程是随机在它们之间切换的,所以调试和监控数据就变的没有什么很大的作用了。但是每个进程的cpu使用会降致50%而且服务器很容易就能承受12万的连接数。我们将以这种方式运行一段时间看看效果如何,还有我们为了更好的监控也会恢复到单进程模式,除非找到一个更好的方法去解决监控每个进程方法。
总的来说,这就是我一天的工作,
管理大型网站和高性能的负载均衡系统以及运维高端技术。以此同时,我们还是需要每天学习更新的知识,庆幸的是,我们可以通过我们的客户平台和你分享这些知识。
- 技术故障排除 - HAProxy 性能和负载
- 浅析如何定位,排除和避免MySQL性能故障
- 报表故障排除:报表性能
- Linux故障排除技术详解
- 使用sysbench检测HAProxy对于Percona XtraDB Cluster的负载均衡和故障检测
- 故障排除和优化视图
- Java性能故障排除工具收集
- SQL Server 2005性能故障排除
- Java性能故障排除工具推荐
- Java性能故障排除工具推荐
- 技术项目 - 负载均衡(HAProxy vs Nginx)
- 故障排除
- 故障排除
- 负载均衡技术之7LVS、Nginx和HAProxy对比总结
- HACMP学习之测试和故障排除
- NFS服务器的安装和故障排除
- TCP/IP工具和故障排除
- 远程监控基础知识和故障排除
- 北京划定63处禁止开发区域 总面积逾3千平方公里 (zz)
- 将execl数据导入Oracle10g
- C#连接远程服务器 映射服务器磁盘 并执行文件 (通过用户名 密码)
- 身份证号码校验规则
- pthread多线程编程整理
- 技术故障排除 - HAProxy 性能和负载
- 利用awk自身变量NR和FNR来处理多个文件
- 数据库技术-为什么在MySQL中只使用InnoDB
- 他在你心里,变的廉价了么:伤感日志
- 什么是阻塞式和非阻塞io流?
- 亚马逊的EC2云计算系统
- js urlencode , encodeURIComponent, escape
- 测试DWR框架出现错误
- 技术项目 - MySQL从库不适合用于备份