应用服务器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不停地fullGC引起的，和妙子分析服务器的gc情况，没发现问题，即使服务器cpu高时GC也是正常的。
3. 会不会是搜索的原因。突然觉得非常有可能呀，请求长时间挂着，当然占cpu啦。分析情况如下：
以下是一个小时的单台isearchmerge的情况。
[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的客户端连接不够用的情况，而当然的解决办法是直接调大客户端的连接。现在想来其它是一种隐藏错误的做法。