mongodb 3.0 WT 引擎效能測試（轉載）

標籤：二次   分區   一個人   xeon   輸送量   批量   適合   softlayer   2.4   

網上轉載來的測試，僅供參考。原文地址：http://www.mongoing.com/benchmark_3_0

本測試過程使用了2類機器。

• 測試均在單機器，單一實例的情況下進行。
• 機器A（cache 12G，即記憶體>資料）：
• 資料：{_id:預設,Name:"Edison",Num:隨機數}
• 使用引擎：WiredTiger
• 索引：除了_id的索引外，Num欄位也有索引。

 

OS：centos6.5 64

Cpu：8核 E5 2407 2.4GHZ

RAM：16G

Disk：300G SATA*2 RAID 1

（點擊查看大圖）

• Insert：

 

同時串連數 op/s

6 15K

10 25K

17 40K

25 50K

50 50K

• Update（表2億條資料）:

 

同時串連數 op/s

6 18K

10 25K

17 32K

25 38K

50 42K

• Query（表2億條資料）:

 

同時串連數 op/s

6 23K

10 42K

17 50K

25 50K

50 50K

• TPS（表2億條資料）：

 

同時串連數 query/s insert/s

6 15K 15K

10 20K 20K

17 21K 21K

25 23K 23K

50 23K 23K

 

• 機器B（cache 12G，即記憶體>資料）：
• 資料：{_id:預設,Name:"Edison",Num:隨機數}
• 使用引擎：WiredTiger
• 索引：除了_id的索引外，Num欄位也有索引。

OS：centos6.5 64

Cpu：24核 E5 2403 1.8GHZ

RAM：64G

Disk：300G SSD RAID 10

  

（點擊查看大圖）

• Insert：

 

同時串連數 op/s

3 23K

4 50K

6 55K

8 65K

14 75K

20 85K

30 95K

35 100K

40 110K

45 150K

50 164K

• Update（表2億條資料）:

 

同時串連數 op/s

3 14K

6 23K

15 44K

20 63K

25 93K

35 130K

40 140K

45 140K

50 150K

• Query（表2億條資料）:

 

同時串連數 op/s

3 10K

6 41K

15 84K

20 120K

25 140K

35 180K

40 190K

45 193K

50 195K

• TPS（表2億條資料）：

 

同時串連數 query/s insert/s

3 10K 10K

6 31K 31K

12 44K 44K

25 60K 60K

35 75K 75K

50 75K 75K

下面在機器B上測試記憶體不足裝下所有資料（只能裝下index/index都無法全部裝下）的情況
記憶體裝下所有資料：

• Query（表3億條資料）:

 

同時串連數 op/s

3 20K

5 40K

8 58K

12 80K

15 90K

22 130K

27 170K

35 180K

50 195K

記憶體僅裝得下index：

• cache：data = 4：10
• Query（表3億條資料）:

 

同時串連數 op/s

3 8K

5 10K

8 16K

12 20K

15 25K

22 32K

27 40K

35 48K

50 57K

記憶體連index都無法全部放下：

• cache：data = 1：10
• Query（表3億條資料）:

 

同時串連數 op/s

3 3.4K

5 4.5K

8 9.3K

12 11K

15 14K

22 20K

27 24K

35 25K

50 34K

（點擊查看大圖）

 

索引全在記憶體中：

cache:data為4：10

索引不全在記憶體中

cache:data為1：10

• 記憶體足夠大的情況下，CPU是瓶頸，CPU表現越好的機器，MongoDB效能越好。

 

 

mongodb官方的報告：

http://www.mongoing.com/archives/862

前言:

MongoDB 3.0的主要側重點是提高效能，尤其是寫效能和對硬體資源的利用率 。為了展示我們在3.0 中取得的成果和如何來應用這些新的改善，我們接下來將發布一系列部落格來比較MongoDB 2.6和3.0的效能。

就像所有的基準測試一樣，這些測試結果不一定適用於你的情境。 MongoDB的使用情境是多種多樣的，採用那種能夠反映你應用程式需求和你將要用來部署的硬體的效能測試是至關重要的。正因如此，目前並沒有一個"標準的"測試程式可以告訴你哪個技術是最適合你的應用程式 。只有你的需求，你的資料，你的基礎設施可以告訴你你所需要知道的。

為了協助我們衡量效能，我們已經與社區合作採用了上百種不同的測試。這些測試反映了使用者所開發的多種多樣的應用程式，和用來部署這些應用的不斷衍變的環境。
YCSB被一些機構用來作為對幾個不同資料庫的效能測試的一個工具。YCSB功能是相當有限的，並不一定能夠告訴你所有你想瞭解的關於你應用程式效能方面的資訊。當然，YCSB還是相當流行的，並且MongoDB和其他一些資料庫系統的使用者也對此比較熟悉。 在這篇文章內我們會比較MongoDB2.6和3.0的YCSB測試結果。

並發量：

在YCSB測試中，MongoDB3.0在多線程、批量插入情境下較之於MongoDB2.6有大約7倍的增長。我們應該期待這種測試情境有最大的改進，因為這是100%寫操作，而WiredTiger的文檔級 並發性控制對在多核處理器伺服器上的多線程測試情境最有協助 。

第二次測試比較了兩個系統上 95%讀取和5%更新的情境。這裡我們看到WiredTiger 有4倍多的輸送量。相比於剛才的純插入情境，這次的效能提升沒有那麼顯著，因為寫操作只佔所有操作的5%。在MongoDB2.6中，並發控制是在資料庫層級，而且寫會阻塞讀操作，從而降低總體的並發量。通過這次測試，我們看到MongoDB 3.0更加細粒的並發性控制明顯提高了總並發量。

最後，對於讀寫操作平衡的情境，我們看到 MongoDB3.0有6倍的並發率。這比我們剛才看到的95%讀 的4倍提高要好一些，因為這裡有更多的寫操作。

響應延遲：

在效能測試中僅僅監測並發量是不夠的，我們還要考慮操作的響應延遲 。對許多操作的響應延遲做一個平均得來的平均響應延遲值不是一個最好的度量指標。對於想要系統有持續良好、低延時體驗的開發人員來說，他們更關注在這個系統中效能最低的操作。 高延時查詢通常用95th和99th百分位元來衡量 – 95th 百分位元表示這個數值（響應延遲）比95%的其他動作都要糟糕（慢）。（有人可能會覺得這種衡量不夠準確： 因為很多網頁請求會使用幾百個資料庫操作， 那麼很可能絕大部分使用者都會經曆到這些99th百分位元的慢響應延遲 ）

在讀操作響應延遲上我們看到在MongoDB2.6和MongoDB3.0之間的差別是非常微小的，讀操作響應延遲很穩定的保持在1ms或者更少的數值內。然而更新操作響應延遲則有相當大的區別 。

在這裡我們通過讀密集型的工作負載來比較更新響應延遲的95th和99th百分位元 。在MongoDB3.0中更新延時顯著改善了，在95th和99th百分位元中幾乎減少了90%。這很重要，提高並發量不應該以更長的延時為代價，因為這將最終降低應用程式 的使用者體驗。

在平衡的工作負載下，更新延遲仍然保持在較低的水平 。在95th百分位元，MongoDB3.0的更新延遲比MongoDB2.6幾乎低90%，而99th百分位元則低80% 。這些改善可以給使用者帶來更好的使用體驗，更加可預測的效能。
我們相信這些針對並發量和響應延遲的測試證明了MongoDB在寫效能上有了顯著的提高。

小改變產生大影響：

在接下來的部落格中我們將描述可以對MongoDB效能產生大影響的一些小改變。作為一個預覽，我們來看一個人們經常忽略的因素。

提供充足的用戶端能力：

YCSB的預設配置只使用一個線程。使用一個單線程，無論是哪個資料庫你的測試結果都會很可憐 。 不要使用單線程基準測試除非你的應用程式運行單線程。單線程測試僅僅測量回應時間，不能測試並發量，而容量規劃對兩個因素都要考慮到。

大多數資料庫都是為多線程用戶端設計的 。通過逐步增加線程數來找到最佳的數量 – 增加更多線程直到你發現並發率停止上升或者回應時間在增加。

考慮為YCSB運行多個用戶端伺服器。一個單一用戶端可能無法產生充足的壓力來測試系統的容量。不幸的是，YCSB沒有讓使用多個用戶端變的簡單，你必須手動去協調多個用戶端的開始和停止，而且你必須自己去綜合各個用戶端的測試結果。

當使用分區的時候，每1，2個分區使用一個mongos，並且每一個mongos要使用一個YCSB用戶端。太多用戶端進程可能會導致系統崩潰，開始會導致響應延遲增加，然而最終會導致CPU崩潰。有時候你需要去控制用戶端的請求量。

尋找在響應延遲和並發量中正確的平衡點是任何效能調優的一個重要組成部分。通過監測延時和並發量，並且通過一系列測試增加線程量，你可以在延時和並發量兩者之間確定明確的關係，並在一個給定工作負載的情況下計算出最佳線程數。

基於這些測試結果我們觀察到以下兩點：

1、 所有操作的99th百分位元直到16線程為止都少於1ms。當多於16線程，響應延遲開始增加。
2、 並發量從1增加到64線程時會不斷增長。在64線程之後，增加線程數不再提高並發量，但是響應延遲卻在增加。

基於這些，應用程式的最佳線程數在16和64之間，且取決於我們更希望降低延遲還是提高並發量。在64線程時，延時看起來依舊很好：99th百分位元的讀取少於1ms， 99th百分位元的寫少於4ms。與此同時，並發量高於13萬/秒

YCSB測試組態

我們測試了許多不同的配置來確定並發量和響應延遲之間的最佳平衡點。
在這些測試中，我們使用了3千萬的文檔和3千萬的操作。文檔包含一個100位元組的欄位（總共151位元組） 並選擇Zipfian作為讀操作選記錄方式。 我們通過逐步增加線程量直到95th和99th百分位元延時開始增加而並發量停止增加的時候確定了最佳線程數，這裡發布的結果就是基於這個最佳線程數的測試。

所有測試使用了複製集，開啟了恢複日誌（Journal），伺服器環境參照了我們的最佳實務來配置。我們始終建議在生產環境要使用複製集。

YCSB用戶端在一個專門的伺服器上運行。每一個複製整合員也在一個專門的伺服器上運行。所有伺服器都是具有下列規格的Softlayer 裸機：

1、CPU: 2x Deca Core Xeon 2690 V2 – 3.00GHz (Ivy Bridge) – 2 x 25MB cache
2、 RAM: 128 GB Registered DDR3 1333
3、 Storage: 2x 960GB SSD drives, SATA Disk Controller
4、 Network: 10 Gbps
5、 Ubuntu 14.10 (64 bit)
6、 MongoDB Versions: MongoDB 2.6.7; MongoDB 3.0.1

mongodb 3.0 WT 引擎效能測試（轉載）