一次數據倉庫報表測試(1)

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中的報表查詢事務一筆都沒有執行。。。。

不一樣的報表寶路都作了屢次嘗試都存在這個問題，那麼是什麼致使的呢？

1. 第一感受仍是GC，好比垃圾回收器用的不合理，像這種大內存，建議採用G1垃圾回收器（具體爲啥G1垃圾回收器合適之後專門給你們寫文章來說GC那些事），通常經常使用的是parNew+CMS，試想發生FULL GC時，新年代+老年代的垃圾對象總大小是很是大的，這就形成很長時間的STW現象。
2. 若是xxBI系統就是採用的G1，發生FULL GC 後，講道理場景從新執行，TPS也不會沒有值。最大的多是GC後，致使緩存失效了，此時咱們的壓測腳本採用的是匿名登錄（就是把壓力機的IP配置到xxBI的白名單，訪問報表就不須要登陸了），懷疑此功能暫時失效。寶路嘗試使用戶正常從瀏覽器登錄xxBI系統進行查詢報表，能正常查詢，退出系統後查看任務管理器，CPU消耗約30%，嗯？此時並無進行壓測，這是爲啥？猜想多是這個操做觸發了緩存。等CPU降下來後，再進行復測TPS曲線正常，再長時間壓測就又出現FULL GC，而後。。。。。。

最後仍是須要xxBI廠商的人來排查這個問題，其實最開始時就有這個現象，可碰巧那天PostgreSQL集羣的人調整了內存相關參數，PostgreSQL集羣的負責人把參數還原後，複測仍然有這個問題。