LevelDB性能分析和表现

Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计。特别是LSM算法。

那么数据库最怕的的随机IO他是如何解决的呢?

先说随机写,它的写都是先记录到日志文件去的,在日志文件满之前只是简单的更新memtable,那么就把随机写转化成了顺序写。在日志满了后,把日志里面的数据排序写成sst表同时和之前的sst进行合并,这个动作也是顺序读和写。大家都知道传统磁盘raid的顺序读写吞吐量是很大的,100M左右是没有问题。在写日志文件的时候,用到是buffer IO,也就是说如果操作系统有足够的内存,这个读写全部由操作系统缓冲,效果非常好。即使是sync写模式,也是以数据累计到4K为一个单位写的,所以效率高。

那么随机读呢?这个它解决不了。但是ssd盘最擅长随机读了。这个硬件很自然的解决了这个问题。

所以leveldb的绝配是ssd盘的raid.

leveldb标准版本编译见浅谈LevelDB在ubuntu 11.04下编译失败的问题,由于标准版本用到了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 kTarget">FileSize = 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性能不好的问题,多线程更新的性能非常好.

(责任编辑:吕光)

时间: 2024-10-24 16:21:06

LevelDB性能分析和表现的相关文章

MySQL性能分析系统

对于MySQL慢查询日志的分析,现已由多种工具来提供:最原始的mysqldumpslow,功能比较齐全的 mysqlsla和percona的 pt-query-digest:以上工具大大提高了DBA来分析数据库的性能效率,减少了过多的猜测过程: 如果能实现定时分析SQL并且进行可视化展示呢? 适用过Query-Digest-UI-master 这个UI插件,在配合 percona的 pt-query-digest工具,只是简单做到一个可视化的结果:如果对于多个服务器的分析,这个表现的就很吃力:

PHP 性能分析与实验:性能的微观分析

在上一篇文章中,我们从 PHP 是解释性语言.动态语言和底层实现等三个方面,探讨了 PHP 性能的问题.本文就深入到 PHP 的微观层面,我们来了解 PHP 在使用和编写代码过程中,性能方面,可能需要注意和提升的地方. 在开始分析之前,我们得掌握一些与性能分析相关的函数.这些函数让我们对程序性能有更好的分析和评测. 一.性能分析相关的函数与命令 1.1.时间度量函数 平时我们常用 time() 函数,但是返回的是秒数,对于某段代码的内部性能分析,到秒的精度是不够的.于是要用 microtime

使用SLS和ODPS进行系统的性能分析

在对计算机系统,尤其是分布式系统的搭建和验证过程中,性能因素是需要着重考虑的因素之一.更激进一点说,判断架构设计的正确与否,性能的好坏.是否可控.是否可预期绝对是最有效的衡量指标. 不幸的是,现有的性能工具大部分是针对代码级的运行时间进行分析,目标是诊断代码的性能bug.但目前我们并没有(或者我还没见到)针对大型的分布式系统的系统级性能分析工具. 虽然这样,但我们可以发扬DIY精神,卷起袖子自己来做这样的性能分析.通过简单日志服务(SLS)对性能日志进行收集,并使用SLS的离线通道将性能相关的数

PHP 性能分析(三): 性能调优实战

在本系列的 第一篇 中,我们介绍了 XHProf .而在 第二篇 中,我们深入研究了 XHGui UI, 现在最后一篇,让我们把 XHProf /XHGui 的知识用到工作中! 性能调优 不用运行的代码才是绝好的代码.其他只是好的代码.所以,性能调优时,最好的选择是首先确保运行尽可能少的代码. OpCode 缓存 首先,最快且最简单的选择是启用 OpCode 缓存.OpCode 缓存的更多信息可以在 这里 找到. 在上图,我们看到启用 Zend OpCache 后发生的情况.最后一行是我们的基准

Winsock五种I/O模型的性能分析

五种I/O模型的性能分析 重叠I/O模型的另外几个优点在于,微软针对重叠I/O模型提供了一些特有的扩展函数.当使用重叠I/O模型时,可以选择使用不同的完成通知方式. 采用事件对象通知的重叠I/O模型是不可伸缩的,因为针对发出WSAWaitForMultipleEvents调用的每个线程,该I/O模型一次最多都只能支持6 4个套接字.假如想让这个模型同时管理不止64个套接字,必须创建额外的工作者线程,以便等待更多的事件对象.因为操作系统同时能够处理的事件对象是有限的,所以基于事件对象的I/O模型不

Mysql Join语法解析与性能分析

原文:Mysql Join语法解析与性能分析 一.Join语法概述 join 用于多表中字段之间的联系,语法如下: ... FROM table1 INNER|LEFT|RIGHT JOIN table2 ON conditiona table1:左表:table2:右表. JOIN 按照功能大致分为如下三类: INNER JOIN(内连接,或等值连接):取得两个表中存在连接匹配关系的记录. LEFT JOIN(左连接):取得左表(table1)完全记录,即是右表(table2)并无对应匹配记录

Pury — 一个新的 Android App 性能分析工具

本文讲的是Pury - 一个新的 Android App 性能分析工具, 手机应用存在的目的,就是在帮助用户做他们想做的事情的同时,提供最好的用户体验 -- 而用户体验的重中之重是应用的性能.但有时候开发者们却以性能为借口,既没有达到既定目标,又写着低质量并难以维护的代码.在这里我想引用 Michael A. Jackson 的一句话: "程序优化守则第一条:别去做它.程序优化守则第二条(仅限于专业人员):别去做它,现在还不是时候." 在开始任何优化之前,我们要先认清问题的症结所在.

PHP 性能分析(一): XHProf & XHGui 介绍

什么是性能分析? 性能分析是衡量应用程序在代码级别的相对性能.性能分析将捕捉的事件包括:CPU的使用,内存的使用,函数的调用时长和次数,以及调用图.性能分析的行为也会影响应用性能. 影响的程度取决于基准测试.基准测试在外部执行,用于衡量应用真实性能.所谓真实性能,即终端用户所体验的应用表现. 什么时候应该进行性能分析? 在考虑是否进行性能分析时,你首先要想:应用是否存在性能问题?如果有,你要进一步考虑:这个问题有多大? 如果你不这样做,将会陷入一个陷阱--过早优化,这可能会浪费你的时间. 为了评

Linux性能分析工具汇总合集

出于对Linux操作系统的兴趣,以及对底层知识的强烈欲望,因此整理了这篇文章.本文也可以作为检验基础知识的指标,另外文章涵盖了一个系统的方方面面.如果没有完善的计算机系统知识,网络知识和操作系统知识,文档中的工具,是不可能完全掌握的,另外对系统性能分析和优化是一个长期的系列. 本文档主要是结合Linux 大牛,Netflix 高级性能架构师 Brendan Gregg 更新 Linux 性能调优工具的博文,搜集Linux系统性能优化相关文章整理后的一篇综合性文章,主要是结合博文对涉及到的原理和性