提纲•集群相关内容•故障定位分析与系统优化•压力测试相关内容•问题解答网络拓扑图防火墙四层交换CMNET被管A管理服务器被管D被管C被管B负载均衡Cache集群•集群(Cluster)是一组对外提供相同服务的服务器组•集群可以通过软件或硬件实现负载均衡(LoadBalance,LB)和高可用(HighAvailability,HA),提高系统可靠性•集群对客户端是透明的,从客户端的角度来看,集群和单独服务器表现一致•集群具有可伸缩性,可以根据系统负荷变化情况方便的调整服务器数量四层交换•四层交换机的基本功能根据IP和端口转发内外IP转换•工作在四层的LB和HALoadBalance分发算法:源地址、最小连接数、轮循等HA机制:基于端口的健康检测•工作在七层的LB和HA根据Cookie或URL中的SessionID作分发,保证Session黏性基于脚本的健康检测,可发出HTTP请求并根据HTTP返回码来判断服务器状态(“/Alteon.jsp”即专为Alteon作健康检测用)•常见的四层交换机:Alteon、RedWare、F5四层交换的会话保持CMWAP用户访问请求用户WAPPortal四层交换WAPGWACK、SYNSYNACK解析HTTP包,寻找Cookie信息HTTPGETa查找Cookie成功,分发到对应服务器b无对照表,根据连接数选择服务器后续HTTP请求数据ACK、SYNSYNACKHTTPGET后续HTTP请求数据处理HTTP请求HTTPResponseTCP三次握手TCP三次握手HTTPResponseHTTPResponse、SYNSYNACK根据源地址IP选择服务器HTTPGET后续HTTP请求数据HTTPGET后续HTTP请求数据处理HTTP请求HTTPResponseTCP三次握手HTTPResponseACK、SYNSYNACKWeblogic集群•可以通过BEA提供的软件实现负载均衡(LoadBalance,LB)和高可用(HighAvailability,HA)•Weblogic集群能通过打开SessionFailOver来保证用户的会话不被丢失•使用集群可在部署时减少出错的机会•由于集群内的服务器需要相互通讯,所以集群会带来额外的开销,并且会减慢系统的启动速度管理与被管管理服务器负责配置和管理被管服务器,不承载业务。被管服务器启动时通过管理服务器获取配置信息并接受管理服务器控制,被管服务器负责承载业务。集群B集群A被管A管理服务器Config.xml被管B被管C被管D被管E集群间通讯•T3集群内服务器使用T3协议(BEA私有协议,使用)进行点对点的通讯•IPMultiCast(IP组播)单播(UniCast)广播(BroadCast)组播(MultiCast)集群内的服务器通过IPMultiCast来进行一对多的通讯,如:心跳包IPMultiCast地址范围:从224.0.0.0到239.255.255.255必须保证集群组播地址的唯一性,否则会导致集群通讯混乱。目前的组播地址规则:237.xxx.xxx.xxx后面几段根据产品和版本变化集群过大会导致集群内通讯堵塞,降低整个集群的性能Session•什么是Session在服务器端保存的一个对象,用于在web应用程序的多个HTTP请求之间跟踪和一个用户的交互。在JAVA中是用哈希表实现,用名值对的方式保存。•Session在服务器端的保存机制使用哈希表保存,以SessionID为主键•服务器端如何确认客户端的身份1、HTTP头信息中CookieCookie:JSESSIONID=BqZsqqGjl!12345678!-876543212、使用URLRewritingGET/a.jsp;jsessionid=Dvb20pXS!12345678!-87654321?a=123HTTP/1.03、服务器端只根据SessionID确认用户身份,所以需要防止用户SessionID泄漏,同时需要加强SessionID复杂度,防止伪造Session容错•Session容错的目的是在某主机或应用当机时,或者在负载均衡设备分发错误时,保证用户会话信息不被丢失•SessionFailOver种类:•NOFailOver:无FailOver•IMR:InmemoryReplication在Session复制备机内存复制•Cookie:使用客户端Cookie保存Session信息•JDBC:使用数据库保存Session信息•File:使用文件系统保存Session信息容错方式性能比较0255075100FileJDBCCookieIMRNOFailoverSession复制•Session复制是把用户会话信息在集群内的Session复制备机上保存一份备份,这样在服务器当机或用户请求被送到错误主机时,Weblogic会从Session复制备机取回备份,从而保证用户会话信息不被丢失•Weblogic使用T3私有协议实现Session复制•Session复制中的复制组的考虑集群内的每个服务器都可以指定自己所在的复制组和自己的优先复制组若无复制组,则系统随机选择复制组Session复制的主机和备机同时更新Session信息时会导致系统线程死锁•Session复制会消耗大量系统性能,并且可能造成系统堵塞,除非业务流程需要,否则不应该打开Session复制•Session复制是一种容错措施,系统的正常运行不能依靠Session复制Session复制状况观察NameStateKnownServersPrimariesSecondaryDistributionssso01RUNNINGsso01sso02sso03sso04sso051sso03:333sso05:555sso02RUNNINGsso01sso02sso03sso04sso051sso04:444sso03RUNNINGsso01sso02sso03sso04sso05333sso01:1sso04RUNNINGsso01sso02sso03sso04sso05444sso02:1sso05RUNNINGsso01sso02sso03sso04sso05555sso06SHUTDOWNn/an/an/asso03、sso05优先复制组为sso01Session复制的注意事项•在Session中保存的数据必须可序列化•保存在Session中的数据发生变化时,必须显式调用setAttribute方法•Session复制会带来额外的性能消耗•页面分帧的情况如果页面分为多帧,则多个子页面的请求可能会同时发到服务器,各子页面都会生成Session,为避免在系统生成多个Session,应该在父页面先把Session生成,或者保证子页面中只有一个页面会生成和修改SessionSessionID格式•SessionID格式:{name}={sessionid}!{pjvmid}!{sjvmid}•使用Session复制的正常情况:=Dv729vLf!12345678!-87654321?p1=1•使用Session复制但备机异常的情况:=Dv729vLf!12345678!NONE?p1=1•未使用Session复制的情况:=Dv729vLf!12345678?p1=1文件句柄数•什么是文件句柄每打开一个文件、socket连接、监听一个端口都需要占用一个句柄•系统需要多少文件句柄数正常情况下系统文件句柄数在1000左右,大并发系统和系统并发量有关weblogic执行线程数+weblogic队列数+backlog长度+1000+冗余•全局文件句柄数和进程文件句柄数•使用sar和lsof可以查看系统当前使用的文件句柄数•文件句柄数不够会出现什么问题?进程文件句柄数不够会导致进程无法继续监听端口、无法写新的日志文件若系统全局句柄数不够还会导致系统无法telnet,只能到现场重启服务器•文件句柄数会消耗系统资源,所以不能过大磁盘缓存•如何查看磁盘缓冲使用情况Linux:topHPUX:kmeminfo•如何减少系统磁盘缓存占用系统内存Linux:核心参数不可调,但系统内存不足时会自动释放HPUX:核心参数可调但系统内存不足时不能自动释放参数:dbc_max_pct建议值:10解释:MaxDynamicBufferCacheSizeasPercentofSystemRAM队列与线程池WebLogicSocketReader线程池执行线程池A系统连接队列执行队列A执行队列B执行线程池B队列与线程池线程池处理线程数的确定系统每秒需要处理的请求数系统处理请求时的平均响应时间线程池队列长度的确定每个保存在队列中的连接都会占用一个系统文件句柄,所以队列不应太大Backlog的确定系统在作垃圾回收时会停止响应,此时操作系统会将接收到的连接保存在系统的连接队列中,若连接队列满,则系统会直接将连接拒绝掉,所以backlog的最小长度应该等于每秒用户请求数×最大垃圾回收时间数据库Servlet/JSPDataSourceMultiPoolPoolPoolDBDBConnetionConnetion•使用连接池是为了减少建立连接的消耗,提高性能•Pool、MultiPool、DataSouce•MultiPool分发算法:HA与LB•连接可用性检查•多余连接的回收(目前不使用)•连接泄漏检测•连接池连接数目确定•若应用需要频繁访问数据库,则数据库连接池的连接数应该和执行线程数保持一致•若只有部分请求需要访问数据库,则数据库连接池连接数可以少于执行线程数(我们的大部分应用属于这种情况)•具体连接数的确定应该根据实际使用时连接池中的等待情况和数据库的使用情况来确定故障定位思路1、检查系统日志,包括StartErrorInfo.txt、nohup、server.log2、检查应用系统错误日志3、检查和kernel的交互日志,包括sgclient和sgbiz,观察日志中的超时请求量及sgbiz日志中的kernel响应时间4、利用bakerror脚本作故障现场备份,然后检查备份下来的各类信息堆栈分析-空闲线程分析线程堆栈的步骤:1、间隔3到5秒,连续作3次ThreadDump;2、使用vi或文本编辑工具查看线程堆栈情况;3、计算各状态线程的数量。正常情况下,大部分线程应该都处于空闲状况。ExecuteThread:'0'forqueue:'run'daemonprio=1tid=0x08895958nid=0x27a6inObject.wait()[48afb000..48afb87c]atjava.lang.Object.wait(NativeMethod)-waitingon0x56e65d10(aweblogic.kernel.ExecuteThread)atjava.lang.Object.wait(Object.java:429)atweblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:153)-locked0x56e65d10(aweblogic.kernel.ExecuteThread)atweblogic.kernel.ExecuteThread.run(ExecuteThread.java:172)堆栈分析-繁忙线程正常情况下,会有少量线程处于繁忙状况,从这些繁忙线程的堆栈可以看到一般都是在处理比较耗时的操作,Portal里面一般是在等待kernel返回消息。若发现大量的线程都在等待kernel返回消息,则说明kernel发生堵塞。若发现比较多的线程处于繁忙状态,但又不是在等待kernel返回消息,则说明