日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 编程资源 > 综合教程 >内容正文

综合教程

leveldb性能分析

發(fā)布時間:2024/6/21 综合教程 29 生活家
生活随笔 收集整理的這篇文章主要介紹了 leveldb性能分析 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

Leveldb是一個google實現(xiàn)的非常高效的kv數(shù)據(jù)庫,目前的版本1.2能夠支持billion級別的數(shù)據(jù)量了。 在這個數(shù)量級別下還有著非常高的性能,主要歸功于它的良好的設(shè)計。特別是LSM算法。

那么數(shù)據(jù)庫最怕的的隨機IO他是如何解決的呢?

先說隨機寫,它的寫都是先記錄到日志文件去的,在日志文件滿之前只是簡單的更新memtable,那么就把隨機寫轉(zhuǎn)化成了順序?qū)?。在日志滿了后,把日志里面的數(shù)據(jù)排序?qū)懗蓅st表同時和之前的sst進行合并,這個動作也是順序讀和寫。大家都知道傳統(tǒng)磁盤raid的順序讀寫吞吐量是很大的,100M左右是沒有問題。在寫日志文件的時候,用到是buffer IO,也就是說如果操作系統(tǒng)有足夠的內(nèi)存,這個讀寫全部由操作系統(tǒng)緩沖,效果非常好。即使是sync寫模式,也是以數(shù)據(jù)累計到4K為一個單位寫的,所以效率高。

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

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

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

我們的測試采用的就是這個版本, 我們分別測試了1000萬, 1億,10億數(shù)據(jù)量下的leveldb表現(xiàn),發(fā)現(xiàn)隨著數(shù)據(jù)集的變化性能變化不大。
由于leveldb默認的sst文件是2M, 在數(shù)據(jù)集達到100G的時候要占用幾萬個文件,我修改了:

version_set.cc:23staticconstintkTargetFileSize = 32 * 1048576;

讓默認的文件變成32M,減少目錄的壓力。

我的測試環(huán)境是:

$uname-r
2.6.18-164.el5#RHEL 5U4
# 10* SAS 300G raid卡,fusionIO 320G, Flashcache,內(nèi)存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大小設(shè)成256M,這樣減少切換日志的開銷和減少數(shù)據(jù)合并的頻率。

同時應(yīng)該注意到db_bench是單線程程序,還有一個compact線程,所以最多的時候這個程序只能跑到200%的cpu, IO util也不是很高. 換句話說如果是多線程程序的話性能還要N倍的提高。

我們來看下實際的性能數(shù)字:

#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 perop)
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 perop)
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
...比較慢待補充

總結(jié): Leveldb是個很好的kv庫,重點解決了隨機IO性能不好的問題,多線程更新的性能非常好.

玩得開心!

總結(jié)

以上是生活随笔為你收集整理的leveldb性能分析的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯,歡迎將生活随笔推薦給好友。