在一次修改nginx配置時候，執行
case:
#/usr/local/nginx/sbin/nginx -t
出現執行命令出現很久沒返回結果，也沒返回成功或是失敗，就是一直卡住的狀態，嚴重影響nginx配置檔案修改。
-t : test configuration and exit //-t就是檢查nginx配置檢查。
，出現此問題之後，開始著手排查原因。
solution：
於是用ps-ef獲取到改程序的pid，想知道這個程序到底在哪一步耗時
ps -ef |grep nginx
拿到pid是3911。
#strace -o output.txt -t -tt -e trace=all -p 3911 //strace命令檢視每一步執行的時間開銷
發現大量fd=5的檔案描述符出現了timeout。
於是進一步檢視fd=5 且程序號為3911的操作，到底在幹嗎：
原來是這一步操作耗時由5s之久，
進一步排查發現，該步操作是用udp協議，請求的是系統的domain服務（即dns服務）
仔細檢視系統/etc/resolv.conf 配置，發現dns的第乙個nameserver 真的是10.1.1.172。
後經確認，此nameserver的所在主機出現故障，還沒維護好。
至此，完成了一次完整的排障經歷。
關鍵點在於：
1、善於用strace定位問題;
2、理解fd（file description） 檔案描述符的含義；
3、思考總結
記一次 MySQL 的慢查優化
最近遇見乙個 mysql 的慢查問題，於是排查了下，這裡把相關的過程做個總結。我首先檢視了 mysql 的慢查詢日誌，發現有這樣一條 query 耗時非常長 大概在 1 秒多 而且掃瞄的行數很大 10 多萬條資料，差不多是全表了 select from tgdemand demand t1 wher...
記一次慢查詢引發的事故
首先，測試環境上線新版本，並且通過黑盒測試以及功能測試。然後，我們就上線了新的版本。但是在執行3天後，整個伺服器大部分介面都失效了，基本上都是timeout。檢查伺服器情況 cpu基本上佔滿了。接著查了資料庫狀態，通過mysql命令show processlist 存在大量的waiting for ...
記一次react專案排bug
最近在做乙個react專案，使用前後端分離的形式，前端傳送請求得到後端響應後重新進行渲染。在一次重新渲染時，react總是報錯 typeerror cannot read property of undefined，通過控制台輸出發現state中的user未被正確的賦值，那麼到底是哪一步除了錯誤呢。...