自上次解決負載均衡導致伺服器飄紅問題後，房產應用伺服器還是會時不時出現cpu負載過高的問題，並經常在半夜0點後，偶爾也在白天。
開始查詢問題原因。
1. 哪些請求太慢？找出了一些慢請求，結果分析後，找不出導致慢的**，而這些慢的請求也是在服務出問題時出現的。
2. cpu高時記憶體是正常的，開始懷疑是不是因為jvm不停地full gc引起的，和妙子分析伺服器的gc情況，沒發現問題，即使伺服器cpu高時gc也是正常的。
3. 會不會是搜尋的原因。突然覺得非常有可能呀，請求長時間掛著，當然佔cpu啦。
分析情況如下：
以下是乙個小時的單台isearch merge的情況。
這是房merge1上isearch的訪問日誌數。20號和26號是應用伺服器在半夜（1點）cpu負載過高的時間。
應用在正常情況（這裡取的時間是上午10點）：
所以正常 250000*2/60/60==139qps
非正常半夜1點（20號和26號）情況：
所以非正常 約500000*2/60/60==287qps
正常半夜1點情況：
這兩天的請求數是有差別的，而這兩天伺服器是正常的，只能說明它撐住了。
可以看出，isearch大約能撐住的qps是，供參考：
能撐住400000*2/60/60==222qps
上面的數字，它反應了搜尋伺服器和應用伺服器的效能。應用伺服器對isearch的請求越來越多時，isearch開始出現超時，當然應用服務 器從isearch那裡取得資料所花費的時間也越來越多，應用端長掛著（因為對isearch是同步），cpu被佔著，負載當然高了。
可以理解成isearch已經不能負荷了。
為什麼晚上不能負荷？
1. 現在應用有老應用和新應用
2. 有大量的安全測試，對isearch的請求都是她媽的,xss,這種東西
a) 半夜健全幫我幹的活：
[web@oldfang1 logs]$ grep 2010:01 koubei-usertrack.log-20101223 | grep /fang/listsell.html | grep alibaba |wc -l 4705 [web@oldfang1 logs]$ grep 2010:01 koubei-usertrack.log-20101226 | grep /fang/listsell.html | grep alibaba |wc -l 50917 26號半夜一點請求老應用list就這麼多。四台老應用不是要200，000一小時，還不算其它的爬蟲。
[root@tfang10 logs]# grep 2010:01 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l 1983 [root@tfang10 logs]# grep 2010:01 koubei-usertrack.log-20101226 | grep /fang/listsell.html |wc -l 2222 26號半夜一點對新應用沒有請求
b) 正常情況下對**list請求：
[root@tfang10 logs]# grep 2010:10 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l 11639 [root@tfang10 logs]# grep 2010:14 koubei-usertrack.log-20101222 | grep /fang/listsell.html |wc -l 13077 [root@tfang10 logs]# grep 2010:14 koubei-usertrack.log-20101224 | grep /fang/listsell.html |wc -l 6911 [root@tfang10 logs]# grep 2010:10 koubei-usertrack.log-20101224 | grep /fang/listsell.html |wc -l 6980 正常情況下，新應用對**list請求也就這麼點，10臺也就120，000一小時。
[web@oldfang1 logs]$ grep 2010:10 koubei-usertrack.log-20101226 | grep /fang/listsell.html |wc -l 2300 [web@oldfang1 logs]$ grep 2010:10 koubei-usertrack.log-20101223 | grep /fang/listsell.html |wc -l 3425 正常情況下，老應用請求是很少的，4臺也就10，000一小時
26號晚上對**isearch請求就遠遠大於正常情況下對isearch請求.
提議解決方案：
1. 我要應用端，控制對isearch的請求，如果關鍵字中出現,xss,，不對isearch發起請求。
2. 看看能不能在服務上控制對安全檢測，即使qps少點也是好的嘛
基本確定是這個問題引起應用伺服器的問題，如果我們把這個問題解決了還是有問題，我們再來排查問題，希望就是它了。
近來觀察，半夜已經沒問題了。 日誌也比較正常了。
今天tfang1在9點半的時候出現問題。排除了其它原因，只能再檢視慢的請求了。檢視9點半的日誌，請求超過1s的，當然查最慢的。 grep 2011:09:3 koubei-usertrack.log-20110116|awk '' >~/broker.log 都是經紀人對**的操作。經紀人說操作很慢，的確定很慢。這些url請求是可參考的，非常集中了，不像剛找問題時，找慢請求，一找亂七八糟什麼都有，連取個cms檔案，取個cache都慢。
相信這是cpu高的最後乙個問題。阿門。
在檢查管理的列表中，有乙個控制重複提交的安全標籤，乙個**因操作多，而用到了五次，一頁10個**。乙個list請求，至少 請求50次.而這個安全標籤是用到了cache.問題就在這裡，cache連線太多，在建立和釋放鏈結時，用掉了太多的系統資源，cpu受不起了。
在detail頁面中也發現，為了過濾掉敏感詞彙，對7個文字運用cache處理敏感詞，又是乙個消耗。
回顧：以前出現過memcache的客戶端連線不夠用的情況，而當然的解決辦法是直接調大客戶端的連線。現在想來其它是一種隱藏錯誤的做法。
效能測試應用伺服器CPU高 執行緒dump
效能測試過程中，我們會去監控資源的使用情況,一般監控哪些方面呢？1 伺服器的資源情況 cpu 記憶體 網路 執行緒 2 資料庫 慢查詢 死鎖 3 中介軟體 redis memcache rabbitmq 某日，在測試監控過程中發現，應用伺服器的cpu非常高。分析 應用cpu高，說明程序非常耗用資源，...
應用伺服器安裝
1.安裝sql server 2008 r2 native client,注意區分cpu是32位還是64位的 2.copy xe2的midas到c windows system32 低版本的midas.dll會報錯 invalid package 3.命令列執行 regsvr32 midas.dll...
應用伺服器負載均衡
應用伺服器負載均衡 一.負載均衡演算法 二.資料傳送到真實伺服器方式 找 算 伺服器 負載均衡演算法 1.輪訓 這個沒什麼可說，伺服器列表乙個乙個迴圈過來。3.隨即 本來就乙個均衡。4.最小請求 看伺服器那個請求數最少，應該是最均衡的方式，也可以理解能力大責任大。資料傳送到真實伺服器方式 1.htt...