問題描述
環境是SLB+2台ECS執行個體,在ECS執行個體上跑的是的LNMP服務,在某一天下午三點中app包載入資料很慢,平時可能一兩秒就能載入完成js,css等樣式 解決方案
1、找到載入慢的網域名稱和URL
訪問後端資料庫,看擷取資料情況,訪問資料正常。
2、查看作業系統CPU、記憶體、負載、網路情況
查看CPU命令:top
查看記憶體命令:free -m
伺服器負載:uptime
網路:ping 網域名稱
檢測完後都沒有問題
3、查看nginx訪問日誌
通過 tail -f 記錄檔 查看,訪問url地址,狀態代碼都是200,證明正常
4、查看資料庫
通過 show full processlist 查看資料庫的整體狀況,正在執行的SQL等情況。
備忘:
這個我沒有執行,因為我前面檢測都沒有問題,也能擷取到資料,返回狀態代碼是200,說明資料庫是沒有問題的。
如果有很多的SQL,有explain檢索下,看看是否需要最佳化
5、查看TCP狀態
命令:netstat -an | awk ‘/^tcp/{++S[$NF]}END{for(i in S) print i,S[i]}’
發現TIME_WAIT的數量有近五千個,後來就先查看核心中tcp相關的參數
> sysctl -a | grep ‘tw’
net.ipv4.tcp_max_tw_buckets = 5000 #TIME_WAIT的數量
net.ipv4.tcp_tw_recycle = 0 #關閉TCP串連中TIME_WAIT sockets的快速回收
net.ipv4.tcp_tw_reuse = 0 #不開啟將TIME_WAIT sockets重新用於新的TCP串連
還有兩個參數是:
①表示開啟SYN Cookies。當出現SYN等待隊列溢出時,啟用cookies來處理,可防範少量SYN攻擊,預設為0,表示關閉
net.ipv4.tcp_syncookies = 1
②TIMEOUT時間
net.ipv4.tcp_fin_timeout = 30
首先修改核心參數:
> cat >> /etc/sysctl.conf << END
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 30
END
> sysctl -p
其次,清理記憶體裡面的資料
> sync
> echo 3 > /proc/sys/vm/drop_caches
執行完上述操作,TIME_WAIT 的數量並沒有降下來
最後將nginx和php串連方式改用sock,不用9000連接埠,TIME_WAIT 的數量才降下來 產生大量TIME_WAIT的原因
一般情況伺服器端不會出現TIME_WAIT狀態,因為大多數情況都是用戶端主動發起串連並主動關閉串連。但是某些服務如pop/smtp、ftp卻是服務端收到用戶端的QUIT命令後主動關閉串連,這就造成這類伺服器上容易出現大量的TIME_WAIT狀態的串連,而且並發量越大處於此種狀態的串連越多。另外,對於被動關閉已連線的服務在主動關閉用戶端非法請求或清理長時間不活動的串連時(這種情況很可能是用戶端程式忘記關閉串連)也會出現TIME_WAIT的狀態。