關於資料庫壓力測試的故事

最近配合某客戶做了一個關於XX系統的壓力測試，其實經過和客戶的溝通得知，客戶此係統上線後壓力並不大，但由於應用方前期的表現不是特別盡如人意，對此不太信任，所以要求本次壓力測試著重觀察。

• 參與方

我、客戶、應用方（我和客戶簡稱甲方，應用方簡稱乙方）

• 環境配置

資料庫：RAC一體機叢集（為方便統計，應用統一連結一個節點）

壓測工具：jmeter

• 壓測場景

大概10個大場景，每個場景有100、200、300 3個級別的併發小場景，每個小場景壓測10分鐘

• 壓測資料量

壓測資料為應用方編造，資料庫大小2G，其中涉及的關鍵業務表資料量大概有40萬，10萬，3萬不等的資料

壓力測試

此前也做過很多次壓力測試，對於資料庫方面來說，主要是蒐集伺服器當時的CPU，記憶體使用，以及關注AWR報告SQL執行部分是否有異常，便於正式上線後，系統資源的分配，從壓測資料量來看，2G資料可以說是很小的資料量，另外併發最大300，對於2G資料來說，也不算大，本以為壓力測試可以順利進行，那也只是理想很豐滿。

插曲一

在測試其中一個場景A 300併發，jmeter壓測工具開始報錯（具體報的什麼錯，暫不追究），乙方給的恢復是資料量太大，達不到300，繼續下一個場景 B，100併發，在進行完這個100併發的場景後，就有了如下對話。

甲方：xxx表資料 上一個場景A 300併發時，還是10萬 ，這個場景B 100併發的場景跑完變成3萬條了。

乙方（壓測人員）：@經理 這個我不是很懂，你幫忙看下。

乙方（經理）：這個我找人處理的，十萬條資料資料量比較大，實際沒有那麼大的

甲方：這在測試呢 你們資料清理了？

甲方：今天把你們做測試資料的表和對應的資料量都寫到方案裡確定下來。

甲方：不要測試過程中刪資料。

甲方：不能為了達到併發標準在哪刪資料，達不到就是達不到，後期可以最佳化的。

甲方：確定下來 測試過程中不要做小動作。

乙方（壓測人員）：刪資料這個我就不知道了，一般壓力測試的時候都不會讓他們做什麼操作的。

從上面的對話，大概對情況有一個瞭解，乙方可能是認為，資料量大所以場景A 300併發報錯，在沒有和甲方溝通的情況下，私下清理了主業務表資料量，不巧被甲方發現，甲方大為不滿。其實壓力測試就是為了確認系統的執行壓力，如果都和乙方那樣，私下清理資料，也就失去了壓力測試的實際意義，在此，給各位奮戰的DBA 和 應用人員一個建議，實事求是，實時溝通。

插曲二

由於壓力測試，每個大場景都有3個不同併發級別的小場景，但是在分析AWR報告時發現，其中SQL執行次數部分並沒有明顯的變化，100併發SQL執行次數30000，200併發SQL執行次數30000多，根據以往的壓測經驗來看，這肯定是有問題的，同時在系統CPU使用來看，也證明了這一點，兩個不同級別的並CPU使用並無明顯差異，然後甲方乙方開始。

甲方：100和200在資料庫後臺執行的SQL次數沒有太大差別

乙方（壓測人員）：10分鐘100個併發，這麼多次；10分鐘200個併發，應該不會變成2倍吧。

乙方（壓測人員）：這個是總次數吧？

甲方：是。

乙方（壓測人員）：那我覺得這個沒問題吧？

乙方（壓測人員）：你說的這個暫時記錄著，回頭他們看下。

乙方（壓測人員）：你說的情形，我諮詢過了， 可能會涉及到修改對應的一個服務裡面的引數。

乙方（壓測人員）：所以今天先100的跑了吧。

看到這裡，基本明白了，前面幾個併發測試等於是白測試了，這也告訴我們，做事還是細緻點好，同時要說服乙方，就要拿出證據，免得雙方扯皮，怪不得客戶提前都說，這次壓力測試要著重點看。假如只是為了應付工作，簡單的蒐集點資料，然後事後再分析，那反工時必然的，吃一塹長一智。

插曲三

壓力測試終於到了最後3個場景，對於前幾個CPU壓力錶現還算正常，起碼是有壓力的，但最後3個場景的CPU壓力幾乎沒有，難道是一體機的效能太好？那也不應該，再說這個場景是關於客戶分析，市場分析的場景，從字面意思看，應該會訪問很多資料表才對，這次又實實在在的分析各個執行的SQL，以及具體涉及的業務表。

甲方：上個場景 客戶分析中 XXXX表是什麼表？

乙方（壓測人員）：我問下去。

甲方：那個客戶分析的場景 資料庫伺服器幾乎沒壓力 後臺顯示訪問比較多的是這張表。

乙方（經理）：剛剛那個是地區省份的篩選。

甲方：哦 客戶分析 後臺的資料來源 只有這一個主表麼？

就在這時，乙方測試人員發了一個哭哭的表情，我就意識到問題有出現了。

乙方（壓測人員）：你一問，我看了一下。

乙方（壓測人員）：xx分析的指令碼，之前調的時候有部分禁掉了。

乙方（壓測人員）：重新跑下xx分析吧，我停了。

甲方：。。。。。。。。。。。。。。。

看來甲方最開始的不信任還是有依據的，這個壓力測試在此之前，乙方已經準備了一週左右，但還是出現各種狀況。

總結

針對此次測試，除了插曲一乙方做的不地道之外，另外2個都是乙方前期準備的問題，在此，我們不對乙方做過於‘積極’的評價。

對於我來說，有以下感悟：

1、不管是對自己或者客戶，做事要以主人公的心態，抱著應付了事，害人害己呀，比如案例中XX方

2、和其他環節的人員溝通不確定性問題時，需要拿出確鑿證據，免得雙方踢皮球

3、良好的溝通是客戶服務的第一環節，或許你能力暫時不夠，但不能糊弄客戶，誰都不是傻子。