首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 服务器 > 应用服务器 >

应用服务器cpu,内存储器占用高

2012-09-07 
应用服务器cpu,内存占用高2010年10月份左右三天两头出现服务器飘红的情况,cpu高,内存有时出现用光的情况。

应用服务器cpu,内存占用高
2010年10月份左右

三天两头出现服务器飘红的情况,cpu高,内存有时出现用光的情况。查看线上服务器一段时间,也没有特别的错误日志,慢请求也是不明显的,在服务器出问题的时间,什么请求都慢,而且多,很难看出哪些请求是有问题的。在监控系统中发现,单台应用的memcache服务器get最高达到 2000/s,为在短时间内解决问题,直接让SA加了两台服务器。似乎有所好转,红的频率有所降低,但在一个星期总会出现。在监控中也似乎没什么发现,后来在应用服务器上查看请求数时发现,负载均衡后还是不太均衡的。有的服务器是3000/m,有的服务器是1000/m.和SA联系后,发现在一组负载均衡上只配置了部分web应用,所以这部分的web应用承载了一半的请求。

2010年11-12月份左右

自上次解决负载均衡导致服务器飘红问题后,房产应用服务器还是会时不时出现cpu负载过高的问题,并经常在半夜0点后,偶尔也在白天。

开始查找问题原因。

1.哪些请求太慢?找出了一些慢请求,结果分析后,找不出导致慢的代码,而这些慢的请求也是在服务出问题时出现的。
2.Cpu高时内存是正常的,开始怀疑是不是因为jvm不停地full GC引起的,和妙子分析服务器的gc情况,没发现问题,即使服务器cpu高时GC也是正常的。
3. 会不会是搜索的原因。突然觉得非常有可能呀,请求长时间挂着,当然占cpu啦。

分析情况如下:
以下是一个小时的单台isearch merge的情况。
[admin@merge1 httpd]$ grep 2010:01 access_merge_101220.log|wc -l359232[admin@merge1 httpd]$ grep 2010:10 access_merge_101220.log|wc -l233854[admin@merge1 httpd]$ grep 2010:01 access_merge_101221.log|wc -l94702[admin@merge1 httpd]$ grep 2010:10 access_merge_101221.log|wc -l257893[admin@merge1 httpd]$ grep 2010:01 access_merge_101226.log|wc -l599050[admin@merge1 httpd]$ grep 2010:10 access_merge_101226.log|wc -l246161[admin@merge1 httpd]$ grep 2010:01 access_merge_101227.log|wc -l414787[admin@merge1 httpd]$ grep 2010:10 access_merge_101227.log|wc -l218420

这是房merge1上isearch的访问日志数。20号和26号是应用服务器在半夜(1点)cpu负载过高的时间。


应用在正常情况(这里取的时间是上午10点):
[admin@merge1 httpd]$ grep 2010:10 access_merge_101220.log|wc -l233854[admin@merge1 httpd]$ grep 2010:10 access_merge_101221.log|wc -l257893[admin@merge1 httpd]$ grep 2010:10 access_merge_101226.log|wc -l246161[admin@merge1 httpd]$ grep 2010:10 access_merge_101227.log|wc -l218420

所以正常 250000*2/60/60==139qps

非正常半夜1点(20号和26号)情况:
[admin@merge1 httpd]$ grep 2010:01 access_merge_101220.log|wc -l359232[admin@merge1 httpd]$ grep 2010:01 access_merge_101226.log|wc -l599050

所以非正常 约500000*2/60/60==287qps

正常半夜1点情况:
[admin@merge1 httpd]$ grep 2010:01 access_merge_101221.log|wc -l94702[admin@merge1 httpd]$ grep 2010:01 access_merge_101227.log|wc -l414787

这两天的请求数是有差别的,而这两天服务器是正常的,只能说明它撑住了。
可以看出,isearch大约能撑住的qps是,供参考:
能撑住400000*2/60/60==222qps


上面的数字,它反应了搜索服务器和应用服务器的性能。应用服务器对isearch的请求越来越多时,isearch开始出现超时,当然应用服务器从isearch那里取得数据所花费的时间也越来越多,应用端长挂着(因为对isearch是同步),cpu被占着,负载当然高了。


可以理解成isearch已经不能负荷了。

为什么晚上不能负荷?

1.现在应用有老应用和新应用
2. 有大量的安全测试,对isearch的请求都是她妈的<script>,xss,<a> 这种东西

a)半夜健全帮我干的活:
[web@oldfang1 logs]$ grep 2010:01 koubei-usertrack.log-20101223 | grep /fang/listsell.html | grep alibaba |wc -l4705[web@oldfang1 logs]$ grep 2010:01 koubei-usertrack.log-20101226 | grep /fang/listsell.html | grep alibaba |wc -l5091726号半夜一点请求老应用list就这么多。四台老应用不是要200,000一小时,还不算其它的爬虫。

[root@tfang10 logs]# grep 2010:01 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l1983[root@tfang10 logs]# grep 2010:01 koubei-usertrack.log-20101226 | grep /fang/listsell.html |wc -l222226号半夜一点对新应用没有请求

b)正常情况下对出售list请求:
[root@tfang10 logs]# grep 2010:10 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l11639[root@tfang10 logs]# grep 2010:14 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l13077[root@tfang10 logs]# grep 2010:14 koubei-usertrack.log-20101224 | grep /fang/listsell.html |wc -l6911[root@tfang10 logs]# grep 2010:10 koubei-usertrack.log-20101224 | grep /fang/listsell.html |wc -l6980正常情况下,新应用对出售list请求也就这么点,10台也就120,000一小时。


[web@oldfang1 logs]$ grep 2010:10 koubei-usertrack.log-20101226 | grep /fang/listsell.html |wc -l2300[web@oldfang1 logs]$ grep 2010:10 koubei-usertrack.log-20101223 | grep /fang/listsell.html |wc -l3425正常情况下,老应用请求是很少的,4台也就10,000一小时

26号晚上对出售isearch请求就远远大于正常情况下对isearch请求.

提议解决方案:
1.我要应用端,控制对isearch的请求,如果关键字中出现<script>,xss,<a>,不对isearch发起请求。
2.看看能不能在服务上控制对安全检测,即使qps少点也是好的嘛

?

基本确定是这个问题引起应用服务器的问题,如果我们把这个问题解决了还是有问题,我们再来排查问题,希望就是它了。

?

2011年1月

近来观察,半夜已经没问题了。 日志也比较正常了。

今天tfang1在9点半的时候出现问题。排除了其它原因,只能再查看慢的请求了。查看9点半的日志,请求超过1s的,当然查最慢的。grep 2011:09:3 koubei-usertrack.log-20110116|awk '{if($1>1000) print $0}' >~/broker.log 都是经纪人对房源的操作。经纪人说操作很慢,的确定很慢。这些url请求是可参考的,非常集中了,不像刚找问题时,找慢请求,一找乱七八糟什么都有,连取个cms文件,取个Cache都慢。

相信这是cpu高的最后一个问题。阿门。

在检查管理的列表中,有一个控制重复提交的安全标签,一个房源因操作多,而用到了五次,一页10个房源。一个list请求,至少请求50次.而这个安全标签是用到了cache.问题就在这里,cache连接太多,在建立和释放链接时,用掉了太多的系统资源,cpu受不起了。

在Detail页面中也发现,为了过滤掉敏感词汇,对7个文本运用cache处理敏感词,又是一个消耗。

回顾:以前出现过memcache的客户端连接不够用的情况,而当然的解决办法是直接调大客户端的连接。现在想来其它是一种隐藏错误的做法。

热点排行