壓測出的問題
同一套程序，之前放在服務器上使用，公司內部壓測和發佈給客戶使用，均未出現問題。後由於客戶業務需求，將其移植到嵌入式平臺。公司內部壓測過程中，出現三種異常。
問題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不足，導致底層接口異常。
總結：
1、服務端壓測，要根據需求配置請求併發數，做好負載均衡。
2、作爲服務端需要關注fd的配置，系統默認的1024往往不能滿足併發需求。
3、同樣的程序，在服務器上沒問題，在硬件資源緊張的嵌入式硬件上很容易出現問題。資源緊張的平臺是檢驗代碼紕漏的很好環境。