我在Fujitsu Siemens Primergy RX200 S3上运行Linux 2.6.22.19和linux-vserver 2.3.0.34用于开发目的. Intel(R)Xeon(R)5140 @ 2.33Ghz,带有4GB RAM(大部分500MB仍然是免费的).服务器有两个用于镜像RAID配置的热插拔250GB：
dev:~# mpt-status --newstyle ioc:0 vol_id:0 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: OPTIMAL flags: ENABLED ioc:0 phys_id:0 scsi_id:1 vendor:ATA product_id:WDC WD2500JS-55N revision:2E01 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff ioc:0 phys_id:1 scsi_id:8 vendor:ATA product_id:WDC WD2500JS-55N revision:2E01 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff scsi_id:0 100% scsi_id:1 100%
我正在运行LVM和ext3.
我们从2007年7月/ 8月左右开始使用这台机器,并且在当天修复的RAM损坏旁边没有问题.而且,基本上,一切都比我们以前的机器好.
然而,性能问题首先在2008年8月左右被注意到,直到最近我才至少对这个问题产生了信心.现在平均有七个vserver正在运行(三台MysqL机器,两台tomcats,三台Apaches,Hudson,CruiseControl,MediaWiki,Samba等).但是没有得到错误的印象,我们在开发人员和其他人访问服务器方面是一家小公司,所以没有那么多(浏览MediaWiki,Hudson自动化在晚上运行,大多数Apache / 程序有很多静态内容).
一旦我安装了munin,我开始看到有趣的东西,特别是在夜晚.因为在每个虚拟服务器中都发现运行(同时,无处不在)负载高达15,17或20之类的虚幻数字.
但最终问题不只是在夜间停留(我开始禁用查找工作,无论如何都没有使用),而且在白天,特别是当我们最近开始一个项目时,我们不得不使用数据库与一个500MB的MysqL转储文件.
我第一次在工作时间导入转储文件(MysqL< dump.sql;在我们的一个运行MysqL实例的虚拟服务器中),定时输出是：
real 71m28.630s user 0m15.477s sys 0m10.185s
由于我没有注意并且正在开会,所以只是我的同事问我服务器上有什么,因为他非常慢.
我在晚上重新进行了测试,在主机上安装了一个vanilla Debian MysqL(不在guest虚拟机内;关闭所有这些)并点击以下数字：
real 48m33.067s user 0m15.397s sys 0m13.517s
我仍然像是的,很好,这是500MB转储文件;转储到InnoDB空间需要大约1GB,这是相当一些数据.我做了一些测试,比如在这样的测试中用vim写一行文件并用strace捕获它：
0.000048 write(1,"\33[?25l\"foo\" \33[78;7H\33[K",22) = 22
0.000033 stat64("foo",0xbfda1f04) = -1 ENOENT (No such file or directory)
0.000033 open("foo",O_WRONLY|O_CREAT|O_TRUNC,0666) = 4
0.000035 write(4,"thios isthis ia a testa\n",24) = 24
0.000144 fsync(4) = 0
7737.631089 stat64("foo",{st_mode=S_IFREG|0664,st_size=24,...}) = 0
0.000084 close(4) = 0
0.000117 write(1,"\33[78;7H[New] 1L,24C written",28) = 28
0.000051 lseek(3,SEEK_SET) = 0
0.000022 write(3,"b0VIM 7.0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0!\21\0\0mark"...,4096) = 4096
0.000052 select(1,[0],NULL,{0,0}) = 1 (in [0],left {0,0})
这对我来说是一个令人难以置信的事实数字.似乎stat64系统调用被迫等待转储操作完成.更不用说在这样的转储期间在MediaWiki中提供页面也需要几分钟.
无论如何,我安排了一个测试时间表与我们的托管公司在夜间测试我们的生产服务器,我有一个完全不同的图片：
real 7m4.063s user 0m2.690s sys 0m30.500s
我被吹走了.我还获得了亚马逊EC2的测试批准,我得到了更低的数字(在m1.large实例上大约5分钟,其中MysqL数据被写入EBS卷以保持永久性).
此外,在导入数据时,每个其他操作都会变得非常慢,以至于事情变得无法使用,负载会快速上升到5或7(尽管似乎并没有真正发生;看起来这些进程开始相互阻塞现在的原因).
然后我开始做bonnie++ tests,看起来像这样(我实际上有一个去年的试运行,我差点忘了).所以这是2008年10月：
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vserver-host 8G 12332 21 12600 3 10290 2 48519 74 52431 6 235.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
vserver-host,8G,12332,21,12600,3,10290,2,48519,74,52431,6,235.8,16,+++++,+++,+++
这是2009年4月的当前版本：
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vserver-host 8G 9705 16 7268 1 4823 1 29620 45 41336 5 73.1 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 11678 15 +++++ +++ +++++ +++ +++++ +++ +++++ +++ 27739 31
vserver-host,9705,7268,1,4823,29620,45,41336,5,73.1,11678,15,27739,31
我不知道在哪里调整什么来摆脱问题,因为我还不完全确定真正的问题在哪里/什么.我想我开始没能看到树木.
更新1：
感谢您到目前为止的反馈,我先选择了一些我可以轻松测试的东西而无需安排维护时间.
首先,我针对/ dev / null测试了MysqL转储：
dev01:~$time MysqLdump -u root -h db01 database-p >/dev/null Enter password: real 0m18.871s user 0m12.713s sys 0m0.512s
系统负载几乎不明显：
10:27:18 up 77 days,9:10,7 users,load average: 0.16,0.75,0.67 [...] 10:27:33 up 77 days,load average: 0.52,0.79,0.69
此测试期间的sar输出也未发现任何特殊情况：
12:11:45 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:11:46 PM dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM dev254-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:11:47 PM dev8-0 5.00 0.00 200.00 40.00 0.18 36.00 20.00 10.00 12:11:47 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:47 PM dev254-1 25.00 0.00 200.00 8.00 0.74 29.60 4.00 10.00
然后我在转储到文件时运行测试：
dev01:~$time MysqLdump -u root -h db01 database -p >foo.sql real 1m7.527s user 0m13.497s sys 0m2.724s
它花费的时间对我来说并不常见,转储以570MB文件结束.
然而,负载非常有趣……
10:30:49 up 77 days,9:14,load average: 0.76,0.89,0.75 10:30:57 up 77 days,load average: 1.34,1.01,0.79 10:31:05 up 77 days,load average: 2.13,1.19,0.85 10:31:13 up 77 days,load average: 2.68,1.32,0.89 10:31:21 up 77 days,load average: 3.79,1.60,0.99 10:31:29 up 77 days,load average: 4.05,1.69,1.02 10:31:37 up 77 days,load average: 4.82,1.93,1.10 10:31:45 up 77 days,9:15,load average: 4.54,1.97,1.12 10:31:53 up 77 days,load average: 4.89,2.08,1.16 10:31:57 up 77 days,load average: 5.30,2.22,1.21 10:32:01 up 77 days,load average: 5.12,2.23,1.22 10:32:05 up 77 days,load average: 5.03,2.26,1.24 10:32:13 up 77 days,load average: 4.62,1.23
……就像是…
12:16:47 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:48 PM dev8-0 116.00 0.00 21712.00 187.17 134.04 559.31 8.62 100.00 12:16:48 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:48 PM dev254-1 3369.00 0.00 26952.00 8.00 3271.74 481.27 0.30 100.00 12:16:48 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:49 PM dev8-0 130.00 0.00 17544.00 134.95 143.78 752.89 7.69 100.00 12:16:49 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 PM dev254-1 1462.00 0.00 11696.00 8.00 2749.12 1407.78 0.68 100.00 12:16:49 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:50 PM dev8-0 128.00 0.00 18400.00 143.75 143.68 1593.91 7.84 100.40 12:16:50 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:50 PM dev254-1 810.00 0.00 6480.00 8.00 1598.99 4911.94 1.24 100.40
在这个测试中,我很快启动了vim来做一个简单的写测试.加载vim本身也很迟钝,但我无法从strace中正确地提取这些信息.只有待处理的stat64调用再次清晰可见：
0.000050 stat64("bla",0xbf98caf4) = -1 ENOENT (No such file or directory)
0.000038 open("bla",0666) = 4
0.000053 write(4,"fooo\n",5) = 5
0.000051 fsync(4) = 0
5.385200 stat64("bla",st_size=5,...}) = 0
0.000073 close(4) = 0
我会尽快附加进一步的文件系统测试.
更新2 /解决方案：
根据Mihai关于MTP设备和RAID配置的反馈,我进一步研究了这个话题.通过lspci我检索了RAID控制器信息：
dev:~$sudo lspci|grep -i lsi 05:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
进入蓝色a在http://www.ask.com/web?q=linux+problem+performance+SAS1068拍摄并找到write performance problem with LSI Logic SAS1068.错误描述进一步链接到博客谈论DELL PE860 performance problem which too uses the SAS1068.
文章提到了LSIUtil which is available from lsi.com的使用.该文章还详细介绍了如何打开写缓存的lsiutil菜单.
毫不奇怪,事实证明这对性能有重大影响.在激活之前：
dev:~# time (dd if=/dev/zero of=bigfile count=1024 bs=1M; sync) 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied,180.902 seconds,5.9 MB/s real 3m8.472s user 0m0.004s sys 0m3.340s
启用写入缓存后：
dev:~# time (dd if=/dev/zero of=bigfile count=1024 bs=1M; sync) 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied,43.7899 seconds,24.5 MB/s real 0m46.413s user 0m0.000s sys 0m3.124s
这就像白天和黑夜,黑色和白色.有时感觉愚蠢是可以的.我可能应该知道RAID控制器默认禁用写缓存.
更新3：
相反,我发现了一个名为diskstat的munin插件,它为所有块设备提供详细的IO,读/写/等等图形.还有一篇非常精美的博客文章,作者名为Graphing Linux Disk I/O statistics with Munin.
