1.背景
最近寶路接到了一個數據倉庫報表POC的壓測任務（就一個廠商為啥還叫POC….有點滑稽），本次記錄下測試過程中遇到的問題及分析問題的思路。
2.測試環境架構圖
發壓策略：LR模擬業務人員->>某BI報表系統->>PostgreSQL集群3.遇到的問題
3.問題及分析
往PostgreSQL集群節點存放文件
PostgreSQL集群四台server是由一個管理節點進行統一管理的（寶路所使用的壓力機無法直接鏈接），往目標服務器存放nmon監控文件就犯難了，即使用xshell從管理節點跳轉到PostgreSQL節點（沒有安裝ftp），在使用xftp打開的仍然是管理節點傳輸文件窗口。
解決方法：使用scp命令
scp nmon admin@192.168.1.111:nmon (在管理節點上執行，將nmon文件copy到指定服務器用戶名目錄下)
scp admin@192.168.10.111:baobiao1_10vu.nmon /home/admin/baobiao1_10vu_111.nmon (把nmon結果文件從遠程主機copy到當前用戶目錄下並重命名）
壓測過程中遇到GC導致的問題
單交易負載測試過程中遇到了GC回收到導致的STW現象，來看一張xxBI 服務器資源消耗圖：
在場景執行約9分半時發生了FUll GC，GC后CPU驟降，磁盤邏輯讀翻了幾倍。當前場景停止后，繼續重跑此場景，xxBI 服務器資源消耗圖：
。。。。再來看下LR的TPS趨勢圖：
action中的報表查詢事務一筆都沒有執行。。。。
不同的報表寶路都做了多次嘗試都存在這個問題，那么是什么導致的呢？
- 第一感覺還是GC，比如垃圾回收器用的不合理，像這種大內存，建議采用G1垃圾回收器（具體為啥G1垃圾回收器合適以后專門給大家寫文章來講GC那些事），一般常用的是parNew+CMS，試想發生FULL GC時，新年代+老年代的垃圾對象總大小是非常大的，這就造成很長時間的STW現象。
- 如果xxBI系統就是采用的G1，發生FULL GC 后，講道理場景重新執行，TPS也不會沒有值。最大的可能是GC后，導致緩存失效了，此時我們的壓測腳本采用的是匿名登陸（就是把壓力機的IP配置到xxBI的白名單，訪問報表就不需要登錄了），懷疑此功能暫時失效。寶路嘗試使用戶正常從瀏覽器登陸xxBI系統進行查詢報表，能正常查詢，退出系統后查看任務管理器，CPU消耗約30%，嗯？此時並沒有進行壓測，這是為啥？猜測可能是這個操作觸發了緩存。等CPU降下來后，再進行復測TPS曲線正常，再長時間壓測就又出現FULL GC，然后。。。。。。
最后還是需要xxBI廠商的人來排查這個問題，其實最開始時就有這個現象，可碰巧那天PostgreSQL集群的人調整了內存相關參數，PostgreSQL集群的負責人把參數還原后，復測仍然有這個問題。