linux – 严重的写性能问题

Linux 2020-05-27
[抱歉,我试图保持简短,但这是不可能的]

我在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.

解决方法

其他海报上有一些关于排除软件和调整RAID性能的好建议.值得一提的是,如果您的工作量很大,那么如果您考虑更换套件,那么使用带电池支持的写缓存的硬件可能是正确的做法.

相关文章

linux进程通信
linux常用进程通信方式包括管道（pipe）、有名管道（FIFO）、...
Linux常用性能工具功能、用法及原理(一)
Linux性能观测工具按类别可分为系统级别和进程级别，系统级别...
curl命令详解
本文详细介绍了curl命令基础和高级用法，包括跳过https的证书...
linux常用命令示例汇总
本文包含作者工作中常用到的一些命令,用于诊断网络、磁盘占满...
linux平均负载的理解及原因排查
linux的平均负载表示运行态和就绪态及不可中断状态(正在io)的...
CPU上下文切换
CPU上下文频繁切换会导致系统性能下降，切换分为进程切换、线...