引言: 在進行效能測試過程中,同事反饋報錯率突然攀升。通過檢視相關紀錄檔和伺服器狀態,發現了一些關鍵資訊。本文將詳細介紹導致報錯率攀升的原因,並提供相應的解決方法。
在使用JMeter進行效能測試時,我們注意到報錯率開始出現異常增長,這引起了我們的關注。為了找出問題所在,我們首先檢視了Pinpoint監控和Nginx紀錄檔。
從Pinpoint監控的反饋中,我們得到了以下錯誤資訊:
502 Bad Gateway: "<html><EOL><EOL><head><title>502 Bad Gateway</title></head><EOL><EOL><body><EOL><EOL><center><h1>502 Bad Gateway</h1></center><EOL><EOL><hr><center>nginx/1.25.0</center><EOL><EOL></body><EOL><EOL></html><EOL><EOL>"
該錯誤表明閘道器出現問題,無法連線到上游伺服器。進一步分析Nginx紀錄檔可以幫助我們瞭解更多情況。
通過檢視Nginx紀錄檔,我們發現大量的以下錯誤:
2023/08/24 15:27:36 [error] 1237#0: *2627178 no live upstreams while connecting to upstream, client: 192.168.0.98, server: , request: "GET /xxx/api/getxxx/Arxxx HTTP/1.1", upstream: "http://xxxserver/gaxxx/api/getxx/ArBxx", host: "192.168.0.96"
這些錯誤表明無法連線到上游伺服器,並指向了一個具體的請求路徑。進一步分析發現,無法連線的上游伺服器為應用服務(192.168.0.98),而Nginx服務為192.168.0.96。
通過以上分析,我們可以得出以下結論:
為了進一步分析問題,執行了執行緒轉儲操作。通過轉儲檔案,發現大量的執行緒阻塞的情況。執行緒阻塞可能會導致應用程式無法正常處理請求,從而導致報錯率上升。
Attaching to process ID 29674, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.191-b12 Deadlock Detection: No deadlocks found. Thread 6572: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.ForkJoinPool.awaitWork(java.util.concurrent.ForkJoinPool$WorkQueue, int) @bci=350, line=1824 (Compiled frame) - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=44, line=1693 (Compiled frame) - java.util.concurrent.ForkJoinWorkerThread.run() @bci=24, line=157 (Interpreted frame)
將轉儲檔案傳送給相應的產品開發人員進行分析和優化非常重要。開發人員可以通過分析執行緒狀態、鎖競爭等資訊來確定阻塞的原因。他們可以採取以下措施來解決問題:
對於效能測試中報錯率攀升的情況,我們通過分析Pinpoint監控、Nginx紀錄檔、應用紀錄檔和執行緒轉儲檔案,定位了問題所在並提出了相應的解決方法。及時監控系統狀態、分析紀錄檔、執行執行緒轉儲操作以及優化應用程式都是關鍵的步驟。通過這些措施,我們可以改善系統效能,並確保系統能夠穩定執行。
在進行效能測試過程中,我們應該充分利用各種工具和技術,及時發現和解決問題,確保系統在高負載情況下仍能保持可靠和高效。只有這樣,我們才能提供優質的使用者體驗,併為系統的持續發展奠定堅實的基礎。
本文來自部落格園,作者:查拉圖斯特拉麵條,轉載請註明原文連結:https://www.cnblogs.com/n00dle/p/17659316.html