服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 部分RAIDarrays的间歇性I / O延迟导致较差的MySQL性能
Intereting Posts
新的IE窗口在受限制的计算机上打开背景 避免在64位Windows Server 2008 R2上使用GUI的技术原因？ 为VPS帐户设置DNS托pipe服务提供商 用于uinstall的yast2命令行选项 250 BONHAM COOLED BY FIRE是什么意思？ DNS名称不在证书上 我想创build一个运行WinXP虚拟实例的PC网格。 什么是最好的方法？ 解压缩没有path 使用Apachelogging一个HTTP标头的多个出现 使用Free / Open BSD + pf作为DDoSfilter Mysql错误2002（HY000）雪豹 如何邮件禁用Exchange Server中不存在的公用文件夹 find正确的winPE驱动程序 Apache – SSL请求在一段时间后停止工作 由于在主path额外的斜杠FTP错误

部分RAIDarrays的间歇性I / O延迟导致较差的MySQL性能

我正在pipe理运行MySQL数据库的裸机服务器以及其他一些软件。 我们看到一些MySQL查询的性能问题，但这些问题间歇性地发生，几乎完全影响UPDATE查询。

举个例子，我有一个特定的查询每15秒运行一次。 大部分时间以毫秒为单位完成，但有时查询分析显示： 

Status Duration starting 0.000026 checking permissions 0.000003 Opening tables 0.000011 System lock 0.000002 init 0.000007 update 0.000052 Waiting for query cache lock 0.000001 update 0.000002 end 0.000001 query end 15.198987 closing tables 0.000023 freeing items 0.000026 logging slow query 0.000014 logging slow query 0.000001 cleaning up 0.000002

我在这个问题上尝试了这些build议，没有任何效果。 然后我开始研究较低级别的项目，因为我注意到其他一些软件也显示出间歇性的缓慢响应。

performance良好时，以下是最佳输出： 

 top - 12:09:48 up 138 days, 21:57, 2 users, load average: 2.35, 1.73, 1.55 Tasks: 392 total, 2 running, 388 sleeping, 2 stopped, 0 zombie %Cpu0 : 16.4 us, 1.3 sy, 0.0 ni, 80.3 id, 1.0 wa, 0.0 hi, 1.0 si, 0.0 st %Cpu1 : 9.3 us, 0.7 sy, 0.0 ni, 89.1 id, 0.7 wa, 0.0 hi, 0.3 si, 0.0 st %Cpu2 : 4.0 us, 0.7 sy, 0.0 ni, 95.0 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 3.0 us, 0.7 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu4 : 10.0 us, 0.7 sy, 0.0 ni, 89.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu5 : 14.9 us, 0.7 sy, 0.0 ni, 84.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu6 : 2.6 us, 0.3 sy, 0.0 ni, 96.4 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu7 : 1.3 us, 0.0 sy, 0.0 ni, 98.0 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 32836768 total, 24516984 used, 8319784 free, 143868 buffers KiB Swap: 0 total, 0 used, 0 free. 15166836 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26264 root 20 0 1255040 81148 17792 S 19.3 0.2 367:38.32 node 1450 root 20 0 1249548 106060 17760 S 7.6 0.3 2612:39 node 30815 root 20 0 1245184 71652 17780 S 5.6 0.2 898:00.21 node 20700 root 20 0 1238644 63004 16812 S 2.3 0.2 635:20.34 node 281 root 20 0 193348 101184 97840 S 2.0 0.3 2832:15 systemd-journal 2974 root 20 0 48404 21688 3812 S 1.3 0.1 1329:51 openvpn 26283 postgres 20 0 235384 45408 42648 S 1.3 0.1 10:17.88 postgres 26284 postgres 20 0 235380 44780 42008 S 1.3 0.1 10:14.81 postgres 25764 root 20 0 1232976 58792 17716 S 1.0 0.2 42:51.01 node 26279 postgres 20 0 235356 45772 43028 S 1.0 0.1 10:13.60 postgres 12793 root 20 0 23956 3300 2488 R 0.7 0.0 0:00.11 top 26280 postgres 20 0 235384 44764 41992 S 0.7 0.1 10:16.64 postgres 27135 postgres 20 0 235380 44932 42156 S 0.7 0.1 10:15.24 postgres 27136 postgres 20 0 235360 44288 41532 S 0.7 0.1 10:15.45 postgres

当它不好时： 

 top - 12:13:19 up 138 days, 22:00, 2 users, load average: 3.34, 2.45, 1.88 Tasks: 393 total, 2 running, 389 sleeping, 2 stopped, 0 zombie %Cpu0 : 11.1 us, 0.0 sy, 0.0 ni, 0.0 id, 87.8 wa, 0.0 hi, 1.0 si, 0.0 st %Cpu1 : 1.3 us, 0.0 sy, 0.0 ni, 75.5 id, 22.8 wa, 0.0 hi, 0.3 si, 0.0 st %Cpu2 : 5.7 us, 0.3 sy, 0.0 ni, 8.4 id, 85.6 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 11.0 us, 0.3 sy, 0.0 ni, 74.3 id, 14.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu4 : 0.7 us, 0.0 sy, 0.0 ni, 87.3 id, 12.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu5 : 1.3 us, 0.0 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu6 : 1.0 us, 0.0 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu7 : 3.0 us, 0.3 sy, 0.0 ni, 93.3 id, 3.4 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 32836768 total, 24870588 used, 7966180 free, 143868 buffers KiB Swap: 0 total, 0 used, 0 free. 15073140 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26264 root 20 0 1252992 109712 17792 S 10.0 0.3 368:16.02 node 1450 root 20 0 1255692 112632 17760 S 4.3 0.3 2612:57 node 30815 root 20 0 1240064 81032 17780 S 4.0 0.2 898:13.71 node 20700 root 20 0 1243764 74472 16812 S 2.3 0.2 635:24.22 node 281 root 20 0 58644 22468 19124 S 1.0 0.1 2832:18 systemd-journal 25764 root 20 0 1240144 64560 17716 S 1.0 0.2 42:53.01 node 2974 root 20 0 48404 21688 3812 S 0.7 0.1 1329:53 openvpn 7 root 20 0 0 0 0 S 0.3 0.0 728:52.82 rcu_sched 770 postgres 20 0 235648 45920 42780 S 0.3 0.1 8:11.67 postgres 5476 root 20 0 0 0 0 S 0.3 0.0 0:00.15 kworker/u16:1 12329 root 20 0 0 0 0 D 0.3 0.0 0:00.18 kworker/2:1 12778 root 20 0 0 0 0 R 0.3 0.0 0:00.25 kworker/2:2 26278 postgres 20 0 232340 17764 15544 S 0.3 0.1 5:38.38 postgres 28478 mysql 20 0 7210212 3.677g 8560 S 0.3 11.7 1849:14 mysqld 30829 postgres 20 0 232340 17484 15272 S 0.3 0.1 14:01.09 postgres 1 root 20 0 28968 5188 2864 S 0.0 0.0 5:44.60 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:12.38 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 75:39.66 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh

在解决Linux中高I / O等待问题的一些build议之后，我运行了iostat -xm 5 。

这是一个正常的输出： 

 avg-cpu: %user %nice %system %iowait %steal %idle 6.05 0.00 0.63 0.80 0.00 92.52 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 2.60 0.00 58.40 0.00 0.64 22.58 0.02 0.32 0.00 0.32 0.29 1.68 sdb 0.00 2.80 0.00 58.20 0.00 0.64 22.66 0.12 2.10 0.00 2.10 1.70 9.92 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md2 0.00 0.00 0.00 24.00 0.00 0.10 8.53 0.00 0.00 0.00 0.00 0.00 0.00 md3 0.00 0.00 0.00 27.80 0.00 0.53 39.19 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 24.20 0.00 0.53 45.02 0.22 9.06 0.00 9.06 2.64 6.40

和一个缓慢的输出： 

 avg-cpu: %user %nice %system %iowait %steal %idle 3.90 0.00 0.28 51.05 0.00 44.77 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 7.20 0.00 42.20 0.00 15.24 739.82 0.35 8.27 0.00 8.27 0.74 3.12 sdb 0.00 7.40 0.00 62.00 0.00 24.69 815.55 110.16 2142.10 0.00 2142.10 16.13 100.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md2 0.00 0.00 0.00 0.40 0.00 0.00 24.00 0.00 0.00 0.00 0.00 0.00 0.00 md3 0.00 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.20 0.00 0.00 8.00 219.50 3880180.00 0.00 3880180.00 5000.00 100.00

sda和sdb是三星SSD 850 EVO 1TB硬盘。 每个都有一个相同的分区表，在RAID1上创build四个md设备： 

 Personalities : [raid1] md3 : active raid1 sda4[0] sdb4[1] 940987072 blocks super 1.2 [2/2] [UU] bitmap: 2/8 pages [8KB], 65536KB chunk md2 : active raid1 sda3[0] sdb3[1] 19514368 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 15617024 blocks super 1.2 [2/2] [UU] md0 : active raid1 sda1[0] sdb1[1] 487104 blocks super 1.2 [2/2] [UU]

md0是/ boot，键入xfs。 md1用于交换，但目前没有被使用。 md2是/，键入xfs。 最后，md3是存储数据的encryption卷（dm-0）的后备设备： 

 LUKS header information for /dev/md3 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha1 Payload offset: 4096

特别困扰我的是，sdb上的I / O负载似乎比sda上的要高得多。 由于这两个磁盘只提供RAID1arrays的成员分区，这看起来不正确。

我检查了sdb的SMART数据，并且运行了短而长的自检，没有发现任何问题： 

 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 8719 - # 2 Short offline Completed without error 00% 8711 -

系统日志显示除了每30分钟智能日志logging温度更改以外，sdb不具有任何条目。

内核版本： 

 Linux no 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

我错过了什么？

基于你的iostat输出， sdb似乎有一个非常长的I / O队列，相应的高等待时间。

为什么这只发生在sdb ，而不是在两个磁盘上？ 这是一个可能的解释：当你第一次configurationRAID设备时， 所有的 sda内容（甚至无效/垃圾）都被复制到sdb 。 这会自动标记在sdb 使用的所有块，为闪存块/页面回收留下很小的空间（只有很小的过度configuration）。 这可能会在消费级磁盘上产生havok，控制器会直接暂停所有的I / O操作来垃圾收集一些闪存块。

encryption的分区加剧了这个问题，这个分区基本上看起来像是磁盘控制器的一个大的二进制博客。

现在做什么？ 如果您的LUKS安装（及其下面的所有I / O堆栈）支持ATA TRIMclosures，则只需发出fstrim -v <mntpoint>命令即可将所有可用空间标记为未使用。 如果有效，我build议你安排一个夜间cronjob在低负载时自动执行它。 在这里看看更多的信息。

如果您的设置不支持TRIMclosures，那么您运气不好：在这种情况下，您必须确保擦除磁盘并重新分区，留下至less25％的空间。 在某些情况下，甚至需要使用hdparm来设置适当大小的Host Protected Area以手动设置更多的过度configuration; 不过，这对三星850 EVO来说不是必须的。