1. 程式人生 > >系統技術非業餘研究 » leveldb效能分析和表現

系統技術非業餘研究 » leveldb效能分析和表現

Leveldb是一個google實現的非常高效的kv資料庫,目前的版本1.2能夠支援billion級別的資料量了。 在這個數量級別下還有著非常高的效能,主要歸功於它的良好的設計。特別是LSM演算法。

那麼資料庫最怕的的隨機IO他是如何解決的呢?

先說隨機寫,它的寫都是先記錄到日誌檔案去的,在日誌檔案滿之前只是簡單的更新memtable,那麼就把隨機寫轉化成了順序寫。在日誌滿了後,把日誌裡面的資料排序寫成sst表同時和之前的sst進行合併,這個動作也是順序讀和寫。大家都知道傳統磁碟raid的順序讀寫吞吐量是很大的,100M左右是沒有問題。在寫日誌檔案的時候,用到是buffer IO,也就是說如果作業系統有足夠的記憶體,這個讀寫全部由作業系統緩衝,效果非常好。即使是sync寫模式,也是以資料累計到4K為一個單位寫的,所以效率高。

那麼隨機讀呢?這個它解決不了。但是ssd盤最擅長隨機讀了。這個硬體很自然的解決了這個問題。

所以leveldb的絕配是ssd盤的raid.

leveldb標準版本編譯見這裡,由於標準版本用到了c++ 0x的特性,在RHEL平臺下沒得到支援,所以為了移植性, basho見這裡為它做了標準c++版本的port, 見目錄c_src/leveldb. 他之所以用c++ 0x標準主要是用到裡面的原子庫,basho的port用了libatomicops搞定這個問題.

我們的測試採用的就是這個版本, 我們分別測試了1000萬, 1億,10億資料量下的leveldb表現,發現隨著資料集的變化效能變化不大。
由於leveldb預設的sst檔案是2M, 在資料集達到100G的時候要佔用幾萬個檔案,我修改了:

version_set.cc:23 static const int kTargetFileSize = 32 * 1048576;

讓預設的檔案變成32M,減少目錄的壓力。

我的測試環境是:

$uname -r
2.6.18-164.el5 #RHEL 5U4
# 10* SAS 300G raid卡,fusionIO 320G, Flashcache,記憶體96G,  24 * Intel(R) Xeon(R) CPU 

top說:

21782 root      18   0 1273m 1.1g 2012 R 85.3  1.2   1152:34 db_bench 

iostat說:

$iostat -dx 5
...
sdb1              0.40     0.00  3.40  0.00    30.40     0.00     8.94     0.02    4.65   4.65   1.58
fioa              0.00     0.00 2074.80  3.80 16598.40    30.40     8.00     0.00    0.13   0.00   0.00
dm-0              0.00     0.00 1600.00  0.00 16630.40     0.00    10.39     0.25    0.15   0.15  24.76
...

該測試中請注意snappy壓縮沒有開啟,如果有壓縮效能還會高很多,因為IO少了一半。
write_buffer_size=$((256*1024*1024)),log大小設成256M,這樣減少切換日誌的開銷和減少資料合併的頻率。

同時應該注意到db_bench是單執行緒程式,還有一個compact執行緒,所以最多的時候這個程式只能跑到200%的cpu, IO util也不是很高. 換句話說如果是多執行緒程式的話效能還要N倍的提高。

我們來看下實際的效能數字:

#1千萬條記錄
$sudo ./db_bench --num=10000000 --write_buffer_size=$((256*1024*1024))
LevelDB:    version 1.2
Date:       Fri May 27 17:14:33 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    10000000
RawSize:    1106.3 MB (estimated)
FileSize:   629.4 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.134 micros/op;   51.8 MB/s      
fillsync     :      70.722 micros/op;    1.6 MB/s (100000 ops)
fillrandom   :       5.229 micros/op;   21.2 MB/s      
overwrite    :       5.396 micros/op;   20.5 MB/s      
readrandom   :      65.729 micros/op;                  
readrandom   :      43.086 micros/op;                  
readseq      :       0.882 micros/op;  125.4 MB/s     
readreverse  :       1.200 micros/op;   92.2 MB/s     
compact      : 24599514.008 micros/op;
readrandom   :      12.663 micros/op;                  
readseq      :       0.372 micros/op;  297.4 MB/s     
readreverse  :       0.559 micros/op;  198.0 MB/s     
fill100K     :     349.894 micros/op;  272.6 MB/s (10000 ops)
crc32c       :       4.759 micros/op;  820.8 MB/s (4K per op)
snappycomp   :       3.099 micros/op; (snappy failure)
snappyuncomp :       2.146 micros/op; (snappy failure)

#1億條記錄
$sudo ./db_bench --num=100000000 --write_buffer_size=$((256*1024*1024))
LevelDB:    version 1.2
Date:       Fri May 27 17:39:19 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    100000000
RawSize:    11062.6 MB (estimated)
FileSize:   6294.3 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.140 micros/op;   51.7 MB/s       
fillsync     :      70.592 micros/op;    1.6 MB/s (1000000 ops)
fillrandom   :       6.033 micros/op;   18.3 MB/s       
overwrite    :       7.653 micros/op;   14.5 MB/s       
readrandom   :      44.833 micros/op;                   
readrandom   :      43.963 micros/op;                   
readseq      :       0.561 micros/op;  197.1 MB/s      
readreverse  :       0.809 micros/op;  136.8 MB/s      
compact      : 123458261.013 micros/op;
readrandom   :      14.079 micros/op;                   
readseq      :       0.378 micros/op;  292.5 MB/s      
readreverse  :       0.567 micros/op;  195.2 MB/s      
fill100K     :    1516.707 micros/op;   62.9 MB/s (100000 ops)
crc32c       :       4.726 micros/op;  826.6 MB/s (4K per op)
snappycomp   :       1.907 micros/op; (snappy failure)
snappyuncomp :       0.954 micros/op; (snappy failure)

#10億條記錄
$sudo ./db_bench --num=1000000000 --write_buffer_size=$((256*1024*1024))
Password: 
LevelDB:    version 1.2
Date:       Sun May 29 17:04:14 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    1000000000
RawSize:    110626.2 MB (estimated)
FileSize:   62942.5 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.126 micros/op;   52.0 MB/s 
fillsync     :      63.644 micros/op;    1.7 MB/s (10000000 ops)
fillrandom   :      10.267 micros/op;   10.8 MB/s        
overwrite    :      14.339 micros/op;    7.7 MB/s  
...比較慢待補充

總結: Leveldb是個很好的kv庫,重點解決了隨機IO效能不好的問題,多執行緒更新的效能非常好.

玩得開心!

Post Footer automatically generated by wp-posturl plugin for wordpress.

相關推薦

系統技術業餘研究 » leveldb效能分析表現

Leveldb是一個google實現的非常高效的kv資料庫,目前的版本1.2能夠支援billion級別的資料量了。 在這個數量級別下還有著非常高的效能,主要歸功於它的良好的設計。特別是LSM演算法。 那麼資料庫最怕的的隨機IO他是如何解決的呢? 先說隨機寫,它的寫都是先記錄到日誌檔案去的,在日

系統技術業餘研究 » leex文法分析的效率

R13B新新增的leex相當於c的lex, 在做文法分析非常方便,但是效率如何呢? leex的example裡面帶了個erlang_scan和erlang標準的釋出版的erl_scan相容,所以我們來對比測試下效率。 注意用R13B03,因為R13B02的erlc漏掉了編譯xrl格式。 以下是實驗

系統技術業餘研究 » leveldb ubuntu 11.04下編譯失敗問題

我在最新的ubuntu11.04下編譯leveldb的時候發現問題,但是在更早前的這個版本很正常: [email protected]:/usr/src/leveldb$ make g++ -c -DLEVELDB_PLATFORM_POSIX -I. -I./include -std

系統技術業餘研究 » fio效能測試工具新添圖形前端gfio

gfio.c: In function ‘gfio_ui_setup_log’: gfio.c:322: error: ‘GtkTreeSelection’ undeclared (first use in this function) gfio.c:322: error: ‘selection

系統技術業餘研究 » 新的工作研究方向

和大家更新下: 做了將近8年資料庫後,我的工作和研究方向將會延伸到虛擬化和計算相關的雲服務,希望能夠和大家一起進步,Happy New Year! 預祝大家玩得開心! Post Footer automatically generated by wp-posturl plugin for w

系統技術業餘研究 » erlang高階原理應用PPT

公司培訓用的 湊合看吧 主要講erlang系統的特點,分佈叢集以及mnesia的使用, 從比較高的角度來看erlang, 讓你有了大體觀. Post Footer automatically generated by wp-posturl plugin for wordpress. No

系統技術業餘研究 » Linux下FioBlktrace模擬塊裝置的訪問模式

我們在做塊裝置調優的時候, 我們關心的是塊裝置是如何被訪問的,也就是訪問模式(比如說每次從什麼地方讀,每次讀多少塊,熱點在哪裡等),至於每次讀寫的什麼資料我們並不關心. 這些模式當然可以自己去構造,但是如果能把真實應用的訪問模式記錄下來,並且在調優的時候能重放,我們就可以一遍又一遍的除錯直到達到最

系統技術業餘研究 » LMbench 實用的微觀效能分析工具

我們在做高效能服務的時候,通常需要避免7宗罪,比如說記憶體拷貝,昂貴的系統呼叫等等。 但是這些罪的代價是多少,我們並不清楚。 在設計的時候,我們會需要根據資料去做方案的取捨。但是這些測量資料哪裡來呢? google大神是個很好的地方,但是有很多缺點,首先你需要的知識是分散的,第二你需要的知識是二手

系統技術業餘研究 » Linux檔案預讀分析以及評估對系統的影響

Linux系統很重要的一個性能提升點就是它的Pagecache, 因為記憶體比IO快太多了,所以大家都想進辦法來利用這個cache。 檔案系統也不例外,為了達到高效能,檔案讀取通常採用預讀來預測使用者的行為,把使用者可能需要的資料預先讀取到cache去,達到高效能的目的。 Linux各個發行版re

系統技術業餘研究 » Erlang open_port極度影響效能的因素

Erlang的port相當於系統的IO,打開了Erlang世界通往外界的通道,可以很方便的執行外部程式。 但是open_port的效能對整個系統來講非常的重要,我就帶領大家看看open_port影響效能的因素。 首先看下open_port的文件: {spawn, Command} Star

系統技術業餘研究 » gen_tcp呼叫程序收到{empty_out_q, Port}訊息奇怪行為分析

今天有同學在gmail裡面問了一個Erlang的問題,問題描述的非常好, 如下: 問題的背景是: 1、我開發了一個服務端程式,接收客戶端的連線。同一時刻會有多個客戶端來連線,連線後,接收客戶端請求後,再發送響應訊息,然後客戶端主動斷連。

系統技術業餘研究 » Fio IO效能測試工具介紹

官網:http://freshmeat.net/projects/fio/ fio is an I/O tool meant to be used both for benchmark and stress/hardware verification. It has support for 13

系統技術業餘研究 » nmon(Linux下很好用的效能監測工具)介紹

The nmon tool is designed for AIX and Linux performance specialists to use for monitoring and analyzing performance data, including: * CPU utiliz

系統技術業餘研究 » gen_tcp接受連結時enfile的問題分析及解決

最近我們為了安全方面的原因,在RDS伺服器上做了個代理程式把普通的MYSQL TCP連線變成了SSL連結,在測試的時候,皓庭同學發現Tsung發起了幾千個TCP連結後Erlang做的SSL PROXY老是報告gen_tcp:accept返回{error, enfile}錯誤。針對這個問題,我展開了

系統技術業餘研究 » 高強度的port(Pipe)的效能測試

在我的專案裡面, 很多運算logic是由外部的程式來計算的 那麼訊息先透過pipe發到外部程式,外部程式讀到訊息, 處理訊息, 寫訊息, erlang程式讀到訊息, 這條鏈路很長,而且涉及到pipe讀寫,上下文切換,這個開銷是很大的.但是具體是多少呢? 我設計了個這樣的ring. 每個ring有

系統技術業餘研究 » Iostat看不到裝置統計資訊的原因分析

最近在把玩些高速的SSD和nvram裝置的時候,發現iostat無法統計到這些裝置的資訊,很是奇怪,於是分析和總結了一把,挺有意思的。 現象描述如下: # uname -a Linux dr4000 2.6.32-131.17.1.el6.x86_64 #1 SMP Wed Oct 5 17:1

系統技術業餘研究 » TCP連結主動關閉不發fin包奇怪行為分析

問題描述: 多隆同學在做網路框架的時候,發現一條tcp連結在close的時候,對端會收到econnrest,而不是正常的fin包. 通過抓包發現close系統呼叫的時候,我端發出rst報文, 而不是正常的fin。這個問題比較有意思,我們來演示下: $ erl Erlang R14B03 (e

系統技術業餘研究 » Linux下非同步IO(libaio)的使用以及效能

Linux下非同步IO是比較新的核心裡面才有的,非同步io的好處可以參考這裡. 但是文章中aio_*系列的呼叫是glibc提供的,是glibc用執行緒+阻塞呼叫來模擬的,效能很差,千萬千萬不要用。 我們今天要說的是真正的原生的非同步IO介面. 由於這幾個系統呼叫glibc沒有提供相應的封裝,所以l

系統技術業餘研究 » Erlang節點互聯失敗原因分析以及解決方案

今天和項仲在部署新系統的時候發現節點間ping不成功的情況,類似 1> net_adm:ping(‘[email protected]’). pang 由於這個問題比較普遍,我就記錄下一步步的排除步驟. 首先從原理上分析下!由於erlang節點間通訊是透過tcp來進行的,所以我們

系統技術業餘研究 » gen_tcp傳送程序被掛起起因分析及對策

最近有同學在gmail上問關於gen_tcp傳送程序被掛起的問題,問題描述的非常好,見底下: 第一個問題是關於port_command和gen_tcp:send的。從專案上線至今,我在tcp傳送的地方遇到過兩次問題,都跟port_command有關係。 起初程式的效能不好,我從各方面嘗試分析和優化