系統技術非業餘研究 » 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下Fio和Blktrace模擬塊裝置的訪問模式
我們在做塊裝置調優的時候, 我們關心的是塊裝置是如何被訪問的,也就是訪問模式(比如說每次從什麼地方讀,每次讀多少塊,熱點在哪裡等),至於每次讀寫的什麼資料我們並不關心. 這些模式當然可以自己去構造,但是如果能把真實應用的訪問模式記錄下來,並且在調優的時候能重放,我們就可以一遍又一遍的除錯直到達到最
系統技術非業餘研究 » 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有關係。 起初程式的效能不好,我從各方面嘗試分析和優化