一次資料倉庫報表測試(1)
1.背景
最近寶路接到了一個數據倉庫報表POC的壓測任務（就一個廠商為啥還叫POC….有點滑稽），本次記錄下測試過程中遇到的問題及分析問題的思路。
2.測試環境架構圖
發壓策略：LR模擬業務人員->>某BI報表系統->>PostgreSQL叢集3.遇到的問題
3.問題及分析
往PostgreSQL叢集節點存放檔案
PostgreSQL叢集四臺server是由一個管理節點進行統一管理的（寶路所使用的壓力機無法直接連結），往目標伺服器存放nmon監控檔案就犯難了，即使用xshell從管理節點跳轉到PostgreSQL節點（沒有安裝ftp），在使用xftp開啟的仍然是管理節點傳輸檔案視窗。
解決方法：使用scp命令
scp nmon [email protected]:nmon (在管理節點上執行，將nmon檔案copy到指定伺服器使用者名稱目錄下)
scp [email protected]: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叢集的負責人把引數還原後，複測仍然有這個問題。