.jpg)
這里還是按照場景來吧，畢竟場景是最能體驗實(shí)用性的。首先說下服務(wù)器配置以及環(huán)境
阿里云ECS云主機(jī)，8G內(nèi)存，4核的CPU，20M帶寬，20G系統(tǒng)盤+200G數(shù)據(jù)盤，centos6.564位，安裝的一件集成lnmp環(huán)境
場景：微信發(fā)紅包
這個場景是很常見的，一般客戶會在整點(diǎn)的時候進(jìn)行一次微信公眾號的廣告推送，這兒時候服務(wù)器的并發(fā)大概在3000到5000左右。說起來這其實(shí)并不算是高并發(fā)，但是服務(wù)器還是崩了，大概需要等待5分鐘之后才能恢復(fù)正常。這有點(diǎn)不應(yīng)該啊，分析原因。查看CPU的利用率并不高，內(nèi)存使用也很正常，在阿里云控制面板里面查看網(wǎng)絡(luò)出口流量滿載，問題大概是清楚了，網(wǎng)絡(luò)原因?qū)е隆?/p>
首先查看靜態(tài)資源，發(fā)現(xiàn)圖片大部分沒有優(yōu)化，于是脫下來進(jìn)行無損壓縮，大概省略了1M左右的大小，提交上去后依然崩潰，服務(wù)器頻繁出現(xiàn)502。
再次檢查頁面的靜態(tài)資源css和js，把常用的js庫替換成CDN以減少請求數(shù)，提交后依然沒有多少變化，502依舊。
于是查看nginx連接數(shù)，使用命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
結(jié)果顯示
TIME_WAIT 3828SYN_SENT 1FIN_WAIT1 107FIN_WAIT2 27ESTABLISHED 661SYN_RECV 23CLOSING 15LAST_ACK 284
乖乖，TIME_WAITE很高，這里務(wù)必說下TIME_WAITE的含義：TIME_WAIT：另一邊已初始化一個釋放。這個是啥意思呢？意思就是服務(wù)器已經(jīng)主動關(guān)閉了，在等待客戶端給一個回應(yīng)，如果客戶端一直沒有回應(yīng)就會出現(xiàn)等待，這個值就會增加。很顯然，這個時候我們需要減少TIME_WAIT的值。
這里只需要修改sysctl.conf的一些參數(shù)即可，編輯/etc/sysctl.conf文件，檢查
? ? ? 是否是這樣的設(shè)置，如果找不到對應(yīng)的，在文件最后加上即可。保存后執(zhí)行
/sbin/sysctl -p
配置即可生效。
20分鐘后繼續(xù)查看nginx連接數(shù)，結(jié)果
TIME_WAIT 87SYN_SENT 1FIN_WAIT1 60FIN_WAIT2 19ESTABLISHED 477SYN_RECV 12CLOSING 2LAST_ACK 100
恢復(fù)正常，網(wǎng)絡(luò)帶寬也降下來了。
但是好景不長，第二次整點(diǎn)開始搶紅包的時候又出現(xiàn)了502。查看進(jìn)程發(fā)現(xiàn)mysqld的CPU占用率很高，導(dǎo)致CPU滿載，服務(wù)器崩潰。修改mysql配置文件，調(diào)整max_connection為30000。其他相關(guān)參數(shù)進(jìn)行了調(diào)整優(yōu)化，情況有所緩解，但是短短幾分鐘之內(nèi)CPU又滿載了。
詭異！于是查看mysql中的進(jìn)程，發(fā)現(xiàn)頻繁的sql查詢，而所查詢的幾個表數(shù)據(jù)量均在10萬左右，判斷是因為沒有設(shè)置索引導(dǎo)致。咨詢后端開發(fā)，果然是只設(shè)置了主鍵。立刻修改，提交上去五分鐘后CPU降下來，穩(wěn)定在10%左右，也沒有出現(xiàn)過502了。
.png)
