問題現象
有客戶反饋我們的產品有時反應很慢，處理會出現超時。
問題分析過程
1.第一反應可能是使用者增加，併發量太大了，詢問了運營，最近使用者註冊資料並沒有猛增。
2.分析access日誌，發現有隔一段時間會出現幾個連續的請求響應時長超過30秒，並且這些請求都是使用乙個thrift服務的，而連redis和其他thrift服務的請求沒有出現延遲的情況，問題出現在該thrift服務。
分析1）分析該thrift服務的日誌，發現介面出現超時的這段時間，該thrift沒有列印日誌，也就是沒有處理請求。這時懷疑是什麼資源用完了，首先想到的是資料庫連線池，該服務是 多資料來源的，並且每個資料庫連線池配置的都比較大，不可能出現連線池使用完的情況；也不可能出現乙個資料庫的連線用完，影響其他資料庫連線。
分析2）thrift客戶端配置的連線池使用完了？也不可能，前2天生產環境也把客戶端連線池配的比較大，按現在的使用者數來說夠用了。
分析3）自己寫工具抽取了access日誌中耗時超過20秒的所有請求，發現請求耗時多的請求都是成堆連續出現，並且第乙個請求都是請求報表介面，檢視thrift服務這些報表介面有些使用者資料很大，有的sql要30多秒。得出的結論是報表介面查詢阻塞了其它thrift介面，那原因又是什麼呢？跟技術總監聊了這個問題，他讓我們看一下thrift服務端處理請求的執行緒數。
分析4）檢視thrift服務端處理的**，org.apache.thrift.server.tthreadedselectorserver.args中預設配置的處理請求執行緒數是5，如果上面說的報表介面連續請求5次，就會出現報表請求阻塞其他請求的現象。在開發環境模擬重現了該問題。
/** the number of threads for selecting on already-accepted connections */
public int selectorthreads = 2;
/*** the size of the executor service (if none is specified) that will handle
* invocations. this may be set to 0, in which case invocations will be
* handled directly on the selector threads (as is in tnonblockingserver)
*/private int workerthreads = 5;
解決方案
1.調整框架，把工作執行緒抽取出來作為可配置引數，生產環境按需調整該引數。
2.把請求耗時的介面抽成乙個單獨的thrift服務，即使報表sql耗時，請求超時也不影響其他業務介面。
記一次生產報too man open files
有一天私有雲無法訪問，馬上聯絡廠商，最後廠商發現好多容器不停重啟，經過日誌檢視發現平台開啟檔案控制代碼太多，很奇怪，就開始排查，最後發現乙個埠，定位到應用spring actuator.這個應用是我為了監控微服務而發布的乙個監控應用，馬上看日誌，發現應用報錯，too many open files，...
記一次生產環境獲取不到redis連線問題排查
最近線上環境總是不穩定，用著用著就會出現獲取不到redis連線的情況，檢視redis伺服器端配置，發現連線數不是很多，那麼為什麼又會出現如此情況呢？首先檢視redis服務端的配置 通過redis cli連線到redis伺服器 redis cli h 127.0 0.1 p 6379 a 密碼 獲取客...
記一次生產故障，nginx503
問題概述 web頁面進行login操作，控制台報503 系統版本 centos 6.8 服務架構 前端兩個nginx 伺服器，可外網，中間兩台業務伺服器，使用docker起兩組服務 後端3臺redis 哨兵 和三颱mongo 問題分析 由控制台報503可知是伺服器內部原因，可能是網路或者服務方面。解...