系统技术非业余研究

ulimit最初设计是用来限制进程对资源的使用情况的，因为早期的系统系统资源包括内存,CPU都是非常有限的，系统要保持公平，就要限制大家的使用，以达到一个相对公平的环境。以下是典型的机器默认的限制情况:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 204800
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 204800
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

但是很多年过去了，情况发生变化了，硬件在过去的时间里面发展的非常迅猛，一个拥有几十个核心的，上百G内存的机器差不多也是白菜价格了。但是软件的限制还是没怎么发生变化，导致一系列使用的问题。其中很重要的文件句柄使用限制尤为明显。

特别是类似web服务器，数据库程序等需要大量的文件句柄，一旦开太小，比如默认(1024),在句柄使用完毕的时候，系统就频繁出现emfile错误
，这时候系统很容易陷入不可用。但是如果设定太大了，又会有这样的副作用。很多服务器程序是事件派遣的，比如说用epoll，程序在启动的时候通常会根据最大的文件句柄数来预留内部的slot，比如说Erlang一个slot貌似要占用几K的资源，如果你设定文件句柄数目太大，就可能无端的浪费了几百M内存。所以要正视这个问题，设定一个合适的值。

通常我们是在shell下用来ulimit -n NNNN来设定新开的进程的文件句柄的限制，但是在一个生产环境下会有如下麻烦：

$ ulimit -n 22222222
-bash: ulimit: open files: cannot modify limit: Operation not permitted
$ sudo ulimit -n 22222222
sudo: ulimit: command not found

JulyClyde(julyclyde@gmail.com)同学介绍解释了这个问题：

shell里不能直接更改，是因为登录的时候pam已经从limits.conf中设置了上限，ulimit命令只能在低于上限的范围内发挥了。

这时候我们通常需要修改/etc/security/limits.conf

# 确认包含下面的内容：
* soft nofile NNNNN
* hard nofile NNNNN

修改后，重现登录shell, 用ulimit -Hn和ulimit -Sn确认修改已生效.

另外淘宝雕梁说：

在linux kernel 2.6.25之前通过ulimit -n(setrlimit(RLIMIT_NOFILE))设置每个进程的最大打开文件句柄数不能超过NR_OPEN (1024*1024),也就是100多w(除非重新编译内核)，而在25之后，内核导出了一个sys接口可以修改这个最大值(/proc/sys/fs /nr_open).具体的changelog在这里

直接在你自己的程序里面绕开文件句柄的限制。

祝大家玩得开心！

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

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

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

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

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…

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

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

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

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

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

我在最新的ubuntu11.04下编译leveldb的时候发现问题,但是在更早前的这个版本很正常：

yufeng@yufeng-laptop:/usr/src/leveldb$ make
g++ -c -DLEVELDB_PLATFORM_POSIX -I. -I./include -std=c++0x -g2 db/db_bench.cc -o db/db_bench.o
In file included from ./port/port.h:14:0,
                 from ./util/coding.h:17,
                 from ./db/dbformat.h:13,
                 from ./db/db_impl.h:9,
                 from db/db_bench.cc:8:
./port/port_posix.h:14:22: fatal error: cstdatomic: 没有那个文件或目录
compilation terminated.
make: *** [db/db_bench.o] 错误 1

Read more…

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

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

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

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

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

玩得开心！