压力测试与故障分析

上传人:第*** 文档编号:53405043 上传时间:2018-08-30 格式:PPT 页数:36 大小:1.70MB
返回 下载 相关 举报
压力测试与故障分析_第1页
第1页 / 共36页
压力测试与故障分析_第2页
第2页 / 共36页
压力测试与故障分析_第3页
第3页 / 共36页
压力测试与故障分析_第4页
第4页 / 共36页
压力测试与故障分析_第5页
第5页 / 共36页
点击查看更多>>
资源描述

《压力测试与故障分析》由会员分享,可在线阅读,更多相关《压力测试与故障分析(36页珍藏版)》请在金锄头文库上搜索。

1、提纲 集群相关内容 故障定位分析与系统优化 压力测试相关内容 问题解答网络拓扑图集群集群(Cluster)是一组对外提供相同服务的服务 器组集群可以通过软件或硬件实现负载均衡(Load Balance,LB)和高可用 (High Availability,HA) ,提高系统可靠性集群对客户端是透明的,从客户端的角度来看,集 群和单独服务器表现一致集群具有可伸缩性,可以根据系统负荷变化情况方 便的调整服务器数量四层交换四层交换机的基本功能根据IP和端口转发内外IP转换工作在四层的LB和HALoad Balance分发算法:源地址、最小连接数、轮循等HA机制:基于端口的健康检测工作在七层的LB和H

2、A根据Cookie或URL中的SessionID作分发,保证Session黏性基于脚本的健康检测,可发出HTTP请求并根据HTTP返回码来判断 服务器状态(“/Alteon.jsp”即专为Alteon作健康检测用)常见的四层交换机:Alteon、RedWare、F5四层交换的会话保持Weblogic集群可以通过BEA提供的软件实现负载均衡(Load Balance,LB)和高可用 (High Availability,HA)Weblogic集群能通过打开Session FailOver来保证 用户的会话不被丢失使用集群可在部署时减少出错的机会由于集群内的服务器需要相互通讯,所以集群会带 来额外

3、的开销,并且会减慢系统的启动速度管理与被管管理服务器负责配置和管理被管服务器,不承载业务。 被管服务器启动时通过管理服务器获取配置信息并接受管理服务器控制 ,被管服务器负责承载业务。集群间通讯T3 集群内服务器使用T3协议(BEA私有协议,使用)进行点对点的通讯IP MultiCast(IP组播)单播(UniCast)广播(BroadCast)组播(MultiCast)集群内的服务器通过IP MultiCast来进行一对多的通讯,如:心跳包IP MultiCast地址范围:从224.0.0.0到239.255.255.255必须保证集群组播地址的唯一性,否则会导致集群通讯混乱。目前的组播地址规

4、则:237.xxx.xxx.xxx后面几段根据产品和版本变化集群过大会导致集群内通讯堵塞,降低整个集群的性能Session什么是Session在服务器端保存的一个对象,用于在web应用程序的多个HTTP请求之间跟踪和一个用 户的交互。 在JAVA中是用哈希表实现,用名值对的方式保存。Session在服务器端的保存机制使用哈希表保存,以SessionID为主键服务器端如何确认客户端的身份1、HTTP头信息中CookieCookie: JSESSIONID=BqZsqqGjl!12345678!-876543212、使用URLRewritingGET /a.jsp;jsessionid=Dvb20

5、pXS!12345678!-87654321?a=123 HTTP/1.03、服务器端只根据SessionID确认用户身份,所以需要防止用户SessionID泄漏,同时需 要加强SessionID复杂度,防止伪造Session容错Session容错的目的是在某主机或应用当机时 ,或者在负载均衡设备分发错误时,保证用户 会话信息不被丢失Session FailOver种类: NO FailOver:无FailOver IMR:In memory Replication在Session复制备机内存复制 Cookie:使用客户端Cookie保存Session信息 JDBC:使用数据库保存Sessio

6、n信息 File:使用文件系统保存Session信息容错方式性能比较Session复制Session复制是把用户会话信息在集群内的Session复制备机上保存一 份备份,这样在服务器当机或用户请求被送到错误主机时,Weblogic会 从Session复制备机取回备份,从而保证用户会话信息不被丢失Weblogic使用T3私有协议实现Session复制Session复制中的复制组的考虑集群内的每个服务器都可以指定自己所在的复制组和自己的优先复制组若无复制组,则系统随机选择复制组Session复制的主机和备机同时更新Session信息时会导致系统线程死锁Session复制会消耗大量系统性能,并且可能

7、造成系统堵塞,除非业务 流程需要,否则不应该打开Session复制Session复制是一种容错措施,系统的正常运行不能依靠Session复制Session复制状况观察Name State Known Servers Primaries Secondary Distributions sso01RUNNINGsso01 sso02 sso03 sso04 sso051sso03 : 333 sso05 : 555sso02RUNNINGsso01 sso02 sso03 sso04 sso051sso04 : 444sso03RUNNINGsso01 sso02 sso03 sso04 sso0

8、5333sso01: 1sso04RUNNINGsso01 sso02 sso03 sso04 sso05444sso02: 1sso05RUNNINGsso01 sso02 sso03 sso04 sso05555sso06SHUTDOWNn/an/an/asso03、sso05优先复制组为sso01Session复制的注意事项在Session中保存的数据必须可序列化保存在Session中的数据发生变化时,必须显式调 用setAttribute方法Session复制会带来额外的性能消耗 页面分帧的情况如果页面分为多帧,则多个子页面的请求可能会同时发到服务器,各子页面都 会生成Session,

9、为避免在系统生成多个Session,应该在父页面先把Session生 成,或者保证子页面中只有一个页面会生成和修改SessionSessionID格式SessionID格式:name=sessionid!pjvmid!sjvmid使用Session复制的正常情况:http:/ http:/ http:/ Dynamic Buffer Cache Size as Percent of System RAM队列与线程池队列与线程池线程池处理线程数的确定系统每秒需要处理的请求数系统处理请求时的平均响应时间线程池队列长度的确定每个保存在队列中的连接都会占用一个系统文件句柄,所以队列不应太大Backlo

10、g的确定系统在作垃圾回收时会停止响应,此时操作系统会将接收到 的连接保存在系统的连接队列中,若连接队列满,则系统会 直接将连接拒绝掉,所以backlog的最小长度应该等于每秒用 户请求数最大垃圾回收时间数据库 使用连接池是为了减少建立连接的消耗, 提高性能 Pool、MultiPool、DataSouce MultiPool分发算法:HA与LB 连接可用性检查 多余连接的回收(目前不使用) 连接泄漏检测 连接池连接数目确定 若应用需要频繁访问数据库,则数据库连接池的连接数 应该和执行线程数保持一致 若只有部分请求需要访问数据库,则数据库连接池连接 数可以少于执行线程数(我们的大部分应用属于这种

11、情 况) 具体连接数的确定应该根据实际使用时连接池中的等待 情况和数据库的使用情况来确定故障定位思路1、检查系统日志,包括StartErrorInfo.txt、nohup、 server.log2、检查应用系统错误日志3、检查和kernel的交互日志,包括sgclient和sgbiz,观察 日志中的超时请求量及sgbiz日志中的kernel响应时间4、利用bakerror脚本作故障现场备份,然后检查备份下来 的各类信息堆栈分析空闲线程分析线程堆栈的步骤: 1、间隔3到5秒,连续作3次ThreadDump; 2、使用vi或文本编辑工具查看线程堆栈情况; 3、计算各状态线程的数量。正常情况下,大部

12、分线程应该都处于空闲状况。“ExecuteThread: 0 for queue: run“ daemon prio=1 tid=0x08895958 nid=0x27a6 in Object.wait() 48afb00048afb87cat java.lang.Object.wait(Native Method)- waiting on (a weblogic.kernel.ExecuteThread)at java.lang.Object.wait(Object.java:429)at weblogic.kernel.ExecuteThread.waitForRequest(Execut

13、eThread.java:153)- locked (a weblogic.kernel.ExecuteThread)at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:172)堆栈分析繁忙线程正常情况下,会有少量线程处于繁忙状况,从这些繁忙线程的堆栈可以看到一般 都是在处理比较耗时的操作,Portal里面一般是在等待kernel返回消息。若发现大量的线程都在等待kernel返回消息,则说明kernel发生堵塞。若发现比较多的线程处于繁忙状态,但又不是在等待kernel返回消息,则说明此处 可能有性能瓶颈,需要优化。“ExecuteT

14、hread: 142 for queue: run“ daemon prio=1 tid=0x0854a2f0 nid=0x27a6 in Object.wait() 444f5000444f587cat java.lang.Object.wait(Native Method)- waiting on (a mon.sgclient.QueObj)at mon.sgclient.SGManager.doIt(SGManager.java:930)- locked (a mon.sgclient.QueObj)at mon.sgclient.SGManager.doIt(SGManager.java:880)堆栈分析堵塞

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 解决方案

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号