leveldb 性能、使用场景评估

　　最近有个业务写远远大于读，读也集中在最近写入，这不很适合采用leveldb存储么，leveldb业界貌似ssdb用得挺广，花了两天时间就ssdb简单做下测试，以下总结。

　　ssdb 是leveldb的redis兼容协议封装，并且实现了主从同步，源码不多易读；主要对redis命令封装，get/set 不说，leveldb 是有序的，相比redis通过scan遍历的命令，利用有序性 list、hset也通过key+fileld/seq - val 方式存储，ttl 会单独存储一个hset 保存过期时间，由一个单独线程定时轮询删除。

　　leveldb 参考：　　

　　http://www.cnblogs.com/haippy/archive/2011/12/04/2276064.html

　　http://blog.csdn.net/houzengjiang/article/details/7718548

测试场景

机器：两台R720XD E5-2620 2.1G (6核12线程)*2/内存128GB/300GB机械硬盘

数据： key: key 10位顺序数字 value: 50字节

并发： 默认情况100连接并发

客户端: 使用erlang erdis模块get/set

 

配置：

leveldb:

        cache_size: 500

        block_size: 1

        write_buffer_size: 64

        compression: no

        max_open_files: 1000

  

数据量：2kw

- 文件大小：1.3GB

- 写速度：7w/s  CPU 250%  mem:30M

- 随机读： 5.5w/s  CPU  100%  mem:1GB

- 并发读写1:10: 读 5k/s 写:5w/s，CPU 250%

总结：总体性能和github给出的相近；leveldb数据存放十分紧凑，因为会对key开启前缀压缩，如果开启snappy后会更小，即使全量缓存到内存，内存消耗也会比redis 少很多。

 

数据量：1.5亿

- 文件大小：9.6GB

- 写速度：7w/s  cpu: 250%  mem:70M

- 随机读:  1.6w/s cpu:100% mem:70M

-并发读写：1: 10: 4k/s 读  5w/s 写 250%

总结：读太随机的LRU cache 无法有效缓存任何数据，请求都要经过文件系统读取，性能下降；但写保性能持不变

 

数据量：10亿

- 文件大小：66GB

- 写速度：7w/s  cpu:250% mem:80M

- 随机读:  1.6w/s cpu:180% mem:80M

-并发读写：1: 10: 4k/s 读:5w/s 写:280%

总结：和1.5亿级别效果保持一致

 

page cache

     leveldb默认缓存meta data、和8M的block；本次测试使用了500M block_cache，从测试效果看，因为随机读，cache只在2k数据级别上起到作用，且带来很高性能提升。

     1.5亿、10亿时，完全依赖kernel 对文件系统的page cache，机器有128GB内存，leveldb 没有使用direct io，文件都缓存，实际运行中不会有磁盘IO。

     那么使用脚本清理：     

     while true;  do echo 1 > /proc/sys/vm/drop_caches;echo clean cache ok; sleep 1; done

 

- 随机读 约160/s  cpu: 5%  mem: 120m  iostat 95%util

- 1并发随机读，100并发写：90/s 读， 1500/s 写，随机读取影响写入速度

总结：

     随机IO在机械硬盘上是完全无解了，只能靠cache扛，相比page cache，block_cache 更有效，应该更加需求增加bock_cache。

     相比增加内存，使用ssd硬盘成本更低。

 

读取系统调用：

open("./var/data/006090.ldb", O_RDONLY) = 27

stat("./var/data/006090.ldb", {st_mode=S_IFREG|0644, st_size=34349641, ...}) = 0

mmap(NULL, 34349641, PROT_READ, MAP_SHARED, 27, 0) = 0x7f0334f76000

madvise(0x7f040457e000, 737280, MADV_DONTNEED) = 0

munmap(0x7f03dc2ab000, 34349599)        = 0

close(27)                               = 0

 

多线程

ssdb 是多线程的，但上面测试效果看有明显多核利用率很低问题，从源码看可以知道：

- 1个主线程，负责网络io

- 10个读线程，负责像scan复杂操作读

- 1个写线程，负责写操作磁盘io

- 1个leveldb 的compact线程

 

     也就是写set 一个主线程负责网络，一个写线程负责leveldb操作；而读get 只有主线程在工作。

 

ssdb相关都没有配置，简单修改源码重新编译：

 

- 10个线程处理读：2.5/s  CPU 450%

     60%消耗在sys，高并发读文件对内核瓶颈

- 减小至3个线程处理读：3.2w/s 280%（相比10线程，更少的CPU消耗，更高的性能）

- 使用LRUCahce 在1kw区间随机读  7w/s ，200%CPU

可靠性

     leveldb 更新前先写日志方式，但默认方式日志mmap是不会做msync，也就是完全依赖操作系统刷磁盘，这样存在机器掉电等意外故障时可能会丢失部分最新消息。支持leveldb:WriteOptions.sync可选参数，但ssdb默认false，改为需要修改代码。

     修改true后，奇怪性能无变化？代码上看并不是每个写都会msync，而是4kbuffer后刷一次。

     那么leveldb 在故障时可能丢时少量数量就是没办法的了，如需要强可靠需要注意。

 

     测测msync速度怎么样呢？

     简单单线程c程序，每写100字节做一次msync，效果：

     服务器2w/s, 我的mac pro ssd 3w/s (此时ssd也没太大优势)

 

     msync 每次都做的话，肯定是有较大的性能影响的，但是可以做group msync；group  msync 会增加延时，就看可接受都少了，如0.1ms，那就就可以以1w/s 脉冲式，批量sync磁盘，保证所有请求都写入磁盘再返回。

 

batch

     leveldb 的写入、修改、删除都是支持优化的batch操作，使用multi_set命令。

 

最佳实战

1. 写性能

     测试中，写入速度一直维持7w/s, 可满足到多需求， leveldb 写入可以到40w/s, 这里受限于ssdb 线程模型无法利用更多的核心。需要的话通过pipline、网卡中断平衡、提高网络、leveldb写线程数 来提高写入性能。

2. 读性能

     一般业务都存在数据热点，可调整cache_size, block_size 提高缓存命中率，block_size 为缓存块大小1K~4M视具体业务value而定。

     如果业务热点度不高，那只能上ssd硬盘了。

     注意使用了page cache，不小心清空会让性能急剧下降，还是尽量配置足够大的cache_size。还有就是启动有个预热过程。

3. compaction

     本次使用的顺序key写入，因为业务上key 都是顺序的，然后一段时间从后往前顺序删除。compaction影响会很小，如果业务大量随机key写入、修改、删除会增加compaction量，需要注意。