同一套程式，之前放在伺服器上使用，公司內部壓測和發布給客戶使用，均未出現問題。後由於客戶業務需求，將其移植到嵌入式平台。公司內部壓測過程中，出現三種異常。
問題1：
大併發壓測，服務程序被killed掉。
問題2：
大併發壓測，服務掛掉，最後的列印為底層的錯誤日誌。
問題3：
大併發壓測，服務掛掉，列印另外的底層錯誤日誌。
對於問題1，開始懷疑是記憶體洩漏，編譯選項中新增-o0 -fsanitize=address -fno-omit-frame-pointer -fsanitize=leak進行記憶體檢測，未發現異常。但是隨著壓測的時間推移，服務占用記憶體還是在緩慢增長。後懷疑是沒有限制請求佇列大小，當消費者速度跟不上生產者速度時，生產佇列堆積變大，使得記憶體增長。伺服器上未出現，是因為伺服器硬體資源遠大於嵌入式板，短期的壓測不至於使服務被系統killed。
降低壓測併發數，記憶體增長導致被killed掉的現象未再出現。
問題2的列印大量日誌中，出現了too many open files，說明是配置的檔案描述符不足。
有兩種可能，一種是控制代碼洩露，同樣的**在伺服器上未出現，在嵌入式板上出現了，控制代碼洩露的可能性不大。通過cat /proc/$id/limits檢視到嵌入式板預設配置的fd數量為1024，而伺服器上被配置為655350。為了驗證問題，加大併發請求執行緒數到1024，問題2立馬復現，修改fd配置問題得到解決。
問題3未能復現，原因可能同問題2，是fd不足，導致底層介面異常。
一次web專案首頁壓測記錄（未完）
公司運營的人員說公司之前的外包web專案每天早上首頁都打不開，領導讓我對首頁做併發壓測，沒有任何業務場景需求給出，只能自己摸索，使用工具是jmeter，首先從50併發開始模擬，50併發的結果如下 是不是很爛，平均響應時間都到了27秒，當時覺得這伺服器真爛，後面分析了一下 其實是問了之前老大肖工，感謝...
壓測介面執行緒數設定 一次介面壓測除錯
系統重構有一段時間了，也陸陸續續的做了資料遷移，業務遷移，作為整個系統的底層服務以及未來整個部門的中颱系統，服務的可用性，穩定性以及效能都至關重要，因此最近在大促之前做了一次核心服務的壓測。當然壓測生產前必須有乙個除錯的過程，所以會在測試環境進行壓測除錯，下面就是對這次壓測除錯的乙個分析和總結。由於...
將壓測的結果儲存 記一次效能壓測
接到乙個需求 乙個應用的效能壓測，在水平擴容後，tps並沒有增加。希望排查下具體問題。症狀表現如下 應用機器為1c1g，k8s負責管理。測試同學在做效能壓測時，發現 4副本和10副本的集群總tps變化不大。首先對壓測方案進行了重新設計 機型先調整為4c8g。單副本壓測，看瓶頸。調整機型，再壓基線。集...