Archive

Archive for the ‘调优’ Category

Linux下pipe使用注意事项

November 9th, 2011 13 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: Linux下pipe使用注意事项

Linux下的pipe使用非常广泛, shell本身就大量用pipe来粘合生产者和消费者的. 我们的服务器程序通常会用pipe来做线程间的ipc通讯. 由于unix下的任何东西都是文件,只要是文件,在读取的时候,,就会设置last access time, 所以pipe也不例外., 但是这个时间对我们没有意义 如果pipe使用的非常频繁的时候会碰到由于设置访问时间导致的性能问题. 这个开销远比pipe读写的本身开销大. 相比文件读写的开销, atime微不足道,但是对pipe来讲就不同了.
这个事情是上次和多隆同学在把玩他的网络框架的时候,无意发现的.

我们来分析下pipe的这部分代码:
Read more…

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

Flashcache使用的误区以及解决方案

October 28th, 2011 6 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: Flashcache使用的误区以及解决方案

flashcache是facebook释放出来的开源的混合存储方案,用ssd来做cache提升IO设备的性能.很多硬件厂商也有类似的方案,比如说LSI raid卡. 但是这个方案是免费的软件方案,而且经过产品的考验,具体参见:
主页:https://github.com/facebook/flashcache
开源混合存储方案(Flashcache): http://blog.yufeng.info/archives/1165
Flashcache新版重大变化: http://blog.yufeng.info/archives/1429

但是flashcache在使用中很多人会有个误区,导致性能很低。首先我们看下flashcache的设计背景和适用场景:

Introduction :
============
Flashcache is a write back block cache Linux kernel module. This
document describes the design, futures ideas, configuration, tuning of
the flashcache and concludes with a note covering the testability
hooks within flashcache and the testing that we did. Flashcache was
built primarily as a block cache for InnoDB but is general purpose and
can be used by other applications as well.

它是为数据库这样的应用的离散读写优化。如果你用在了顺序读写,就有非常大的性能问题。
那么为什么呢?我来分析下:

flashcache把内部的cache空间分成很多set, 是以set而不是整体为单位提供cache以及flush后备操作. 也就是说当一个set里面的dirty page达到一个预设的值的时候,就需要把这么dirty page 淘汰并且flush到后备设备去,以便腾出空间给更热的数据使用。
那么每个set多大呢?

To compute the target set for a given dbn
target set = (dbn / block size / set size) mod (number of sets)
Once we have the target set, linear probe within the set finds the
block. Note that a sequential range of disk blocks will all map onto a
given set.

set默认是 512*4k = 2M大小,也就是说如果你的这个set刚好是一个文件所在的块,而且每次这个文件都不停的顺序写,很快这个set都变成dirty, 那么flashcache就选择马上刷,这样加速效果就没有了。

幸好作者Mohan认识到了这个问题,提供了解决方案:

见https://github.com/facebook/flashcache/blob/master/doc/flashcache-sa-guide.txt 中的章节Tuning Sequential IO Skipping for better flashcache performance

引入了配置参数来解决这个问题:

dev.flashcache..skip_seq_thresh_kb:
Skip (don’t cache) sequential IO larger than this number (in kb).
0 (default) means cache all IO, both sequential and random.
Sequential IO can only be determined ‘after the fact’, so
this much of each sequential I/O will be cached before we skip
the rest. Does not affect searching for IO in an existing cache.

这样你可以把太大的顺序操作给过滤掉了,大大提升性能。

祝玩得开心!

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

Linux高速缓存使用率调查

June 1st, 2011 15 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: Linux高速缓存使用率调查

Linux的高速缓存pagecache对性能的影响至关重要,但是实际系统中我们的利用率如何呢,特别是具体到每个设备的利用情况。

从下图我们可以很清楚的看到:

我们知道IO请求由vfs发起,经过pagecache缓存,挡不住的就落实到io设备去,那么统计这个利用率就很简单。 我们只要知道挡不住的IO的比例就好了。

我写了个systemtap脚本来解决这个问题:
Read more…

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

Categories: Linux, 调优 Tags: ,

Linux文件预读分析以及评估对系统的影响

May 31st, 2011 3 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: Linux文件预读分析以及评估对系统的影响

Linux系统很重要的一个性能提升点就是它的Pagecache, 因为内存比IO快太多了,所以大家都想进办法来利用这个cache。 文件系统也不例外,为了达到高性能,文件读取通常采用预读来预测用户的行为,把用户可能需要的数据预先读取到cache去,达到高性能的目的。

Linux各个发行版readahead的实现差异很大,我们这里重点讨论2.6.18, RHEL 5U4发行版的行为.文件预读的实现主要在mm/readahead.c中,代码才603行。 预读的流程大概是这样的,用户需要文件页面的时候入口函数do_generic_mapping_read会委托page_cache_readahead来进行处理。它首先判断用户的IO是顺序的还是随机的,如果是随机的就没啥好预读. 如果是顺序的话,那么预读算法会根据用户上一次读取的页面的使用情况评估出预读的窗口,决定要读多少页面。读页面的模块会先检查要读取页面在pagecache里面是否已经存在,如果不存在的话就需要发起IO请求,读取相应的页面。还有个路径就是在文件mmap缺页的时候filemap_nopage调用do_page_cache_readahead进行预读, 不过这个路径在通常的环境里概率不高.

这个预读的关键参数有3个: 用户的req_size, 预读算法评估出来的nr_to_read,以及实际上IO读取的页面数actual。

接下来我们就是要查看系统是如何运作的,所以我首先写了个systemtap脚本叫做ratop.stp来获取这些数据:
Read more…

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

leveldb性能分析和表现

May 30th, 2011 21 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: leveldb性能分析和表现

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

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

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

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

所以leveldb的绝配是ssd盘的raid.
Read more…

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

Categories: Linux, 源码分析, 调优 Tags:

disktop per设备per应用层面的IO读写统计

May 16th, 2011 5 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: disktop per设备per应用层面的IO读写统计

我们在调优IO 密集型的应用是通常需要知道IO的使用情况. 但是iostat只能知道系统全局的,iotop只能知道每个应用的, 我们有时候需要细化到每个应用对每个设备的使用情况. 比如说mysql数据库我们通常把日志和数据分开到不同的设备, 那我们需要知道数据读写多少,日志读写多少,分开的了解.

目前还没有工具能够很轻松的了解. 幸运的是systemtap自己带的disktop可以帮我们做到,位于/usr/share/doc/systemtap/examples/io/disktop.stp.
Read more…

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

商品库MySQL优化实践

April 11th, 2011 11 comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: 商品库MySQL优化实践

在刚刚结束的Qcon 2011北京会议上我做了以下的分享:

淘宝商品库是淘宝网最核心的数据库之一,采用MySQL主备集群的架构,特点是数据量大且增长速度快,读多写少,对安全性要求高,并发请求高。

演讲内容包括淘宝商品库硬件的选型决策, 安全性和性能的平衡,特别是创新引入PCI-E Flash卡和Flashcache作为Cache提高IO性能,在保证安全性的前提下就包括MySQL、InnoDB引擎、文件系统、系统Page Cache、 IO调度算法、DM层(Flashcache)、Raid卡、设备驱动在内的整条IO路径的Cache进行优化,进一步挖掘了系统IO的潜能,重点介绍优化过程中的一些经验教训、测量手段和工具。

玩得开心!

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

Categories: Linux, 调优 Tags: ,