fio测试进程kill后果

这几天测试io调度器,脚本内容大概是:创建很多cgroup组,再启动一堆fio进程分别在这些cgroup之间反复随机的挪动,然后pkill -9 fio杀死所有fio进程,再重头来一遍,看是否会panic或者内存泄漏。结果发现,运行一个多小时后就会发生oom,用free命令看内存有大量的cache无法释放。

诡异,难道是我的代码有内存泄漏,退掉我的patch后再测试,还是发生oom;从2.6.32-279变成2.6.32-220,还有oom;变成2.6.32-358,还有oom。怪了,这要是这么容易内存泄漏,早就应该发现了,何至于这么简单的用例也会出错。

在我打算试试upstream的内核之前,ipcs看了一眼,看见一堆共享内存没有释放,顿时捶胸顿足——这个问题以前遇到过的呀!是fio工具本身会创建shm区域,正常退出它会去释放,一旦被kill,这个shm区域就白占内存了。以前都遇到过了,这次居然还花两天犯同样的错误,真该反省啊。

iothrottle测试报告

[原写于2013年2月]

如果一台服务器上跑很多应用,对资源的隔离当然是不言而喻的,但是很多时候,你即使在一台机器上就跑一个应用,也可能需要资源控制。比如,你的服务器是提供在线查询服务的,数据放在硬盘上,部分热数据在内存中,一切顺利,但是,某天你在这台服务器上scp数据文件过来时,发现磁盘被拷文件的操作压得喘不过气,以至于查询服务都受到了影响,那这时该怎么办?当然,我们可以用scp -l 来限制拷贝的带宽,避免对磁盘的巨大压力,但如果同步数据不是用的scp,是用户自己的某个工具或者是自己写的某个程序,那么还需要去改程序吗?难道每个用户开发的程序都要带上控制带宽和资源使用率的功能?

现在比较建议的解决办法是用cgroup来隔离资源,而到io层面,常用的就是iothrottle。iothrottle已经在公司的生产环境中使用,最近运维考虑扩大使用范围,所以针对运维和DBA的一些疑问,我做了一些iothrottle的测试,不是什么高深的测试方法,但是确实能回答使用者的一些问题,测试报告见

kernel.taobao.org

希望能给大家一些帮助,和信心

cubieboard试用手记

[原写于2012年12月]

前一阵子买了一块Cubieboard,就是类似RaspberryPi的ARM板子,之所以选Cubieboard而不是RaspberryPi是因为Cubie的配置更高??1Ghz的ARM核(全志A10),1G的DDR内存,4G的NAND,还带一个SATA口(做为一个靠廉价存储混饭吃的loser,我热爱SATA口)。
板子拿到手,跟照片一模一样,Tom Cubie(Cubieboard的设计者)同学不欺我也。可回收的纸盒子也很可爱。

cubieboard

开始是用wiki上提供的Buildroot方法把编译好的image烧到板子上的NAND里,可以成功启动到Linux 3.4.5 kernel,字符终端,可以联网,但是毕竟系统工具都是用busybox攒的,太少,不够方便,也没有包管理工具。此root系统带有一个CedarXPlayer工具,可以看1080p的视频,即使是高清的rmvb都很流畅(这小板子确实厉害),但是,这个神奇的CedarXPlayer工具不支持快进快退甚至连暂停都不支持,而且退出播放时需要用Ctrl + c,纯属测试工具。

所以,还是改用SD卡启动,论坛上有人提供了BerryBoot,用它可以直接把linaro(可以理解为ARM版的ubuntu)装到SD卡上,能成功进到图形界面,只是分辨率有点低。但此时我再用vlc看rmvb的时候就变得特别卡了,想来是跟显卡驱动有关系,于是按论坛上的说法装了显卡驱动,但还是不好使,只好发邮件问Tom Cubie,他非常耐心的回答了我:
CedaX 是Allwinner自己的一个框架,http://linux-sunxi.org/CedarX
Linux下媒体播放你可以看看这个
http://linux-sunxi.org/VLC
我按照文档里的步骤装了VLC,居然不出图像。嗯,我还需要好好琢磨琢磨。
Cubieboard不光是能做高清播放机,那个sata口加上板子上的 2 pin 的电源口,完全可以接一个2.5寸的笔记本硬盘(或者有钱的话,一个SSD)。想想看,一个5V电压2A电流的ipad充电器,就可以带动一个基于ARM的NAS(Cubieboard加一块2.5寸硬盘),才10瓦功耗的NAS呀,放在家里,可以下个BT,做个共享,看个电影,还是很有优势的。
同事何燕峰送了我一个小机箱,我便把Cubieboard和一个3.5寸的硬盘(实在找不到2.5寸的,3.5寸的硬盘光靠Cubieboard上的2 pin电源口是带不动的,要另外供电,因为2.5寸硬盘只需要5V的电压,而3.5寸硬盘需要12V和5V两种电压)一起放进机箱里,还挺合身:

cubieboard

想测一测Cubieboard最多能支撑多少tcp长链接(当然,是比较空闲的链接)。
我的cubieboard上安装的是linaro(其实就是linux),首先得调节单个进程打开的句柄数(修改/etc/security/limit.conf),然后还要修改sysctl里tcp_mem等网络参数(具体配置可以参考这里1, 2) 然写了一套简单的TCP链接客户端和服务端的代码。Server端用epoll模型; Client端创建500个链接然后把fd放入数组里,每个connection每5秒发送128字节。
开始测试时,在cubieboar上我分别对5个端口启动了5个Server,客户端(我的笔记本)则是用脚本不停的创建Client实例。
测试结果:cubieboard可以支撑到10万个tcp长链接,网络流量稳定保持在3.75MB/s,此时系统内存还有大约300MB free(总共1G),CPU idle在20%左右
cubieboard只有网口没有网卡(也就是没有network controller),所有的收包解包都由CPU完成,所以能支持的流量比较有限,不过撑个10万的闲链接还是没问题的。
还想了解一下cubieboard对https的支撑能力,于是我又在cubieboard上装了tengine(在arm上编译还挺顺利,连warning都没有),配上https签名(参加这里)再用ab压力测试,ab压测脚本是:

ab -n 20000 -c 20 -k url

测试结果:访问https的QPS为755, 访问http的QPS为1269
看来用cubieboard搭个小网站是绰绰有余了,一个小的聊天服务器兴许也可以。

猜猜Cubieboard的设计者Tom Cubie同学多大?2010年的本科毕业生。人家都有自己的事业了。想想我自己,三十好几的人了,还在给人修bug、做测试、调性能,还不招人待见,真是惭愧。
我以后要多向Tom Cubie同学学习。