本文记录了一位朋友处理WAS宕机问题的经历，主要问题是网站因大量文件下载导致频繁死机。通过调整架构引入IHS，并对网站进行优化，包括首页静态化、配置IHS进行动静分离等措施，最终解决了问题。
下文是网上看到的一位朋友处理was宕机的记录，和我项目上一般遇到的was宕机问题差别较大（我们项目是上一般was宕机主要是oom、线程池满、非常少量的连接池满，另外我们的项目上基本上都用ihs或者硬件分发设备如F5或redware等），他这里处理问题分析的过程还是记录蛮详细的，最后关于监控和针对其问题对IHS插件配置这也说了下，如果遇到类似问题没准可以借鉴一下，呵呵。
http://www.webspherechina.net/home/space.php?uid=201&do=blog&id=56444
http://www.webspherechina.net/home/space.php?uid=201&do=blog&id=54852
继续去年没写完的文档，由于时间比较忙一直没来得及总结。虽然系统已经上线运行快4个月了。中间出了一些大大小小的问题，下面就一一说明。
上次是写到第3点：附件上传数据流量测试
文件上传的测试，通过测试工具进行测试基本上没发现太大的问题，不过由于测试环境的网络比较好，所以也很难发现问题。正式上线之后文件的上传这块也没太大的问题，因为有问题也最多是上传不了数据。J
但是对于附件的下载这块却没有进行比较好的测试，导致上线的2个星期都出现了一个大问题。
问题主要出现在网站这块， 由于网站上有提供不少帮助文档、安装包程序的下载，同时网站的访问量也非常大，导致网站频繁死机。 最多的一天死8次机，最短时间是在启动之后5分钟就down 机了。
先说网站服务环境：
操作系统： RHEL 5.5
应用服务器： WAS 7 单节点 。部署了3个应用分别是： cms 是网站， fileStorage_war 是附件目录及下载应用，qyww 是数据查询应用
数据库：Orcale 11g
从环境的配置上来说，也可以看出比较大的问题，网站这种面向公众的服务，其压力可能比内网的业务系统的服务压力还要大，这点由于我们设计上的疏忽导致了频繁死机的重要原因之一。
其实一开始为什么会这种设计，是因为我们做过网站的压力测试，可以支持到4000的并发访问，而且这个测试结果是由专门的测试公司做的，有了这个数据，我们项目组上对于网站这块才没太多的关注，在服务器配置上也没做集群。而且这个网站又是一个政府事业部门的网站，按照惯例我们认为访问的人不会太多。谁知道结果真是出人意料，内网的业务系统没怎么死机，反而外网的网站却是频繁死机。客户因为这个，都打电话投诉到北京总部去了。
真是血的教训啊。。。废话不说了，直接说怎么解决问题吧。
解决方案一：
由于时间比较紧，为了增加网站的稳定性和访问量支持，就需要对网站的部署架构进行调整，增加服务器配置，同时采用集群的方式来支持网站应用。目前的单节点一旦出现问题，就会导致整个服务都停掉，如果采用集群的话再加上IHS做动静分离，起码从稳定性上能够得到很大的保证。
这种方式应该是比较好的解决办法，但是我们一提出来就遭到客户痛骂。为啥呢？服务器的设备采购早就做完了，没有服务器用了。因为客户的预算也是要审批的，而且客户也不会为了这个再去采购新的服务器，客户对于我们以增加设备来解决问题的办法也很反感，骂完一顿之后，连旧设备都不给一台，要求我们在现有设备基础上解决问题，。
没办法这个方案就此无疾而终了，谁要我们一开始没设计好呢，事后要再追加设备是没这么简单的事情了。
解决方案二：
巧妇难为无米之炊，看来短时间无法解决down机的问题了。只能先找到具体出问题的地方了。再针对性优化网站了。整个优化过程走了不少弯路，有些地方是改了之后又改回来。
以下是监控和分析处理和优化过程：
第1天：白天做压力，100个时开始监控到泄漏，但之后几千并发没未宕机！（说明网页访问的压力还能承受住）
第2,3天周六日：经过讨论，有人认为首页的太多的iframe 或导致并发太高而且重复引用JS，影响性能。因此由设计人员查看代码，实现去iframe和采用页面缓存oscache技术改写首页。（走了弯路...）
同时考虑启用IHS进行请求转发，静态化文件处理。
第4天：在前次的修改中，由于操作系统内码问题和程序需要变化，没有来及启用IHS，加上积压的访问下载需要，导致今天更为严重的死机现象（5次）。
(走了弯路的结果就是离目标越来越远，情况更加严重！)
不得已，晚上先把IHS装上，以便监控请求日志。
第5天：上午监控，网站正常，was正常且内存几乎不变化，下载快,netstat监控约1500链接;Http进程20个，每个占280M内存，逐渐占满OS内存。17点死机。（19点钟reboot，到21:22分，分析IHS日志，共有2702个附件下载。预计白天比这要多）(说明网站存在大量的下载，而且很多都是下载工具产生的连接，例如迅雷。这种下载会产生大量连接，并且长期暂用！)
第6天：下午17点前死机（今天1次）。应该是was堆满。有jc和dump，分析jc有log 写锁或等待。发现Downloadservlet（下载的处理程序）有未关闭连接等问题，修改为不用流而直接跳转到HTTP静态直接下载。
(说明下载的程序有问题，经过分析，需要将下载的工作交给IHS来处理，走WAS的话容易导致死锁，线程等待。)
第7天：未死机。监控系统内存满，WAS JVM的heap满，有死机的征兆。人为重启。
第8天：白天正常。18点多系统宕机崩溃，产生jc和dump。
第8天以后的死机，确定是OSCache组件不稳定，在WAS环境下出现了内存泄露，最后去掉OSCache，但页面速度比较慢，需要5秒才能打开。项目组最后解决方法是：将首页静态化，目录菜单静态化。
（从弯路上饶了回来）
总结最终的解决办法：
网站的网页的压力基本上还是能承受住，虽然可能首页人多的是会慢一些，问题主要出在文件的下载这块。下载的程序是通过WAS直接处理的，导致大文件下载长期暂有连接和数据库连接，最终导致系统崩溃。
解决措施：
1、网站首页静态化，所有的菜单栏等数据库访问量较多的地方也静态化处理。
2、安装IHS， 通过IHS转发请求到 WAS上的网站服务。因为IHS对于长连接的请求会有中断处理，有些超时没有响应的请求会自动关闭，这点WAS好像就比较难处理。
3、将文件下载的工作通过IHS静态化文件进行处理。幸好我们的所有附件都是放在文件服务器上，可以通过配置静态化目录，来实现对这些文件的访问，同时屏蔽掉WAS下面的文件下载程序应用包。
4、调低应用中的日志级别，因为日志级别和调试输出的大量数据，导致WAS可能会忙于进行文件IO操作，反应降低，然后循环恶性发展，使系统处于假崩溃状态！
最终网站服务器的部署环境如下：
操作系统： RHEL 5.5
应用服务器： WAS 7 单节点+ IHS
WAS参数：
数据源连接池：200
JVM堆大小： 256M到1024M
启用 servlet 高速缓存
会话最大1000，允许溢出，会话超时2分钟。 因为网站基本上没什么会话数据需要保存，所以设短一点，避免暂用大量内存。
线程池50到100，允许溢出
HIS配置文件httpd.conf关键参数：
LogLevel error (调整日志级别)
#CustomLog logs/access_log common (屏蔽该日志)
Alias /fileStorage "/nfs/datafile/" （指定静态化文件目录）
（调整IHS的最大并发数）
ServerLimit 16
StartServers 5
MinSpareServers 5
MaxSpareServers 15
MaxClients 600
MaxRequestsPerChild 3000
KeepAlive On （调整IHS的请求的最长连接时间以及超时时间，由于网站的特殊性，所以连接不能太长，不然占用资源不释放，就会容易导致死机或者无法访问）
MaxKeepAliveRequests 500
KeepAliveTimeout 5
数据库：Orcale 11g
整个优化到这里基本上就完了。 下面是一些配置上面的心得，希望对大家有用。
1、分析网站连接问题的脚本和工具：
1）分析哪种tcp状态数量异常：
netstat -nat|awk '{print awk $NF}'|sort|uniq -c|sort –n
在网站访问量压力较大情况性下，如果发现time_wait、Fin_wait1等较多，考虑修改linux系统etc/sysctl.conf文件。
可参考文档：http://wenku.baidu.com/view/7a04e2d284254b35eefd3408.html
2）将请求80服务的client ip按照连接数排序：
netstat -nat|grep ":80"|awk '{print $5}' |awk -F: '{print $1}' | sort| uniq -c|sort –n
用于查找恶意连接IP。
3）使用HttpWatch软件
在需要分析网页下载效率时使用。避免网站页面中（特别是首页）出现较大图片、JS等对象。通过该软件可以看到各个URL的访问时间，便于针对性优化。
2、动静分离的配置：
WAS+ IHS动静分离的配置在网上查了下，有个几个方法:
1) 一个比较麻烦的方法就是屏蔽静态内容通过 WebSphere Application Server 中的 File Serving 功能从 WAR 文件返回的功能。需要修改一堆配置文件，然后要重新产生插件等等。 比较麻烦，而且容易出错，这里就不讲了。大家有兴趣可以参考：
http://space.itpub.net/14789789/viewspace-628556
2) 第二种比较简单的就是把静态化的文件直接放到 IHS 服务器，通过ＩＨＳ直接处理，不走WAS。本项目就是采用的这种。
3) 第三种就是购买 WebSphere Edge Server（简称 Edge Server）产品来实现了。
下面主要讲第二种的配置：
前面讲到项目中专门有一个下载的程序，处理附件的下载，但是最终产生了问题，从而通过IHS来代替该功能，而直接处理静态文件的下载。
处理步骤：
a) 修改： /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml 文件，
将其中的：
<UriGroup Name="default_host_server1_zxwzappNode01_Cluster_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/qyww/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/cms/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/fileStorage/*"/>
UriGroup>
中的高亮部分删除，改成如下：
<UriGroup Name="default_host_server1_zxwzappNode01_Cluster_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/qyww/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/cms/*"/>
UriGroup>
表示，屏蔽所有针对fileStorage目录访问的请求，都不会转发到ＷＡＳ服务器上，而是直接通过ＩＨＳ服务器进行处理。
这里需注意：如果WAS应用中有 /* 的应用这种配置，则该项修改会无效，因为 /* 表示所有的路径都必须走WAS应用服务器，就会导致无法配置动静分离。
b) 修改： /opt/IBM/HTTPServer/conf/ httpd.conf 文件，在该文件的最后加上：
Alias /fileStorage "/nfs/datafile/"
表示，所有针对 fileStorage 目录访问的请求，都会通过 IHS服务器转发到 服务器的 /nfs/datafile/ 目录下去访问。 而 /nfs/datafile/ 目录下的文件就是我们所有的附件、静态文件的存放目录。
大家仔细研究/plugin-cfg.xml 可能会发现，只要是我们在WAS下部署了的应用，都会在这个文件中出现一个访问目录。 如果大家用第一种方式配置动静分离，可能会发现，这个文件会变化非常大，里面只要是涉及到动态需要Java处理的路径，在这个里面都会重新生成一个Uri。 例如 *.jsp ，XXservlet 等。
所以，我们有个简单的方法来实现动静分离， 那就是直接修改plugin-cfg.xml 这个文件， 把必须要WAS处理的 路径都加入到这个文件中。 然后把静态的文件类型以及文件路径都剔除出去。 例如 *.jpg , *.js 这种，然后把这些文件全部放到IHS 的静态化目录下。这样IHS 就会把静态化的文件先处理了，然后动态的请求URL再转发给WAS处理。
比较好的一个设计思路就是，把所有的静态文件，例如图片，JS等，都放到一个统一的目录下，各个应用中要用的话，就统一引用这个目录下的文件，这样，静态化的时候，只需要对这个应用目录进行静态化，其他的应用配置就基本上不用改了，否则的话你把所有的需要动态处理的路径都列出来也是非常麻烦的一个事情，万一列少了一个，就会导致请求处理不了。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14710393/viewspace-754662/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14710393/viewspace-754662/
扫一扫
791
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
