在Mysql中执行大插入时，我得到了很多等待时间。 我正确地假设我有一个磁盘I / O问题？ 是的，我正在虚拟机上运行Mysql。
Innodb_buffer_pool hit rate is %100 innodb_flush_method = '' innodb_log_file_size = 250M innodb_flush_log_at_trx_commit=1 $iostat -dx 10 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util xvda 0.00 2514.09 0.10 1483.22 0.80 31958.44 21.55 39.04 26.00 0.64 94.91 xvda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvda2 0.00 2514.09 0.10 1483.22 0.80 31958.44 21.55 39.04 26.00 0.64 94.91 dm-0 0.00 0.00 0.10 3983.82 0.80 31870.53 8.00 163.34 39.84 0.24 94.91 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util xvda 0.00 2206.21 0.00 1336.24 0.00 28342.74 21.21 41.85 31.43 0.72 96.02 xvda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvda2 0.00 2206.21 0.00 1336.24 0.00 28342.74 21.21 41.85 31.43 0.72 96.02 dm-0 0.00 0.00 0.00 3542.44 0.00 28339.54 8.00 165.48 47.09 0.27 96.02 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 $ top top - 11:57:19 up 88 days, 11:38, 3 users, load average: 1.44, 1.54, 1.60 Tasks: 80 total, 2 running, 78 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 1.0%sy, 0.0%ni, 44.5%id, 53.2%wa, 0.0%hi, 0.0%si, 0.7%st Mem: 16777216k total, 13791264k used, 2985952k free, 166988k buffers Swap: 2129912k total, 44k used, 2129868k free, 7157368k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3910 mysql 15 0 13.2g 5.6g 6760 S 1.7 34.8 4:50.09 mysqld 1 root 15 0 10364 740 620 S 0.0 0.0 0:00.29 init 2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:02.77 ksoftirqd/0 4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 5 root 10 -5 0 0 0 S 0.0 0.0 0:00.08 events/0 6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper 7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread 9 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch 10 root 10 -5 0 0 0 S 0.0 0.0 0:01.95 xenbus 15 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 kblockd/0 16 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0 20 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 khubd 22 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod 84 root 15 0 0 0 0 S 0.0 0.0 0:00.01 khungtaskd 87 root 10 -5 0 0 0 S 0.0 0.0 1:37.10 kswapd0 88 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0 218 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused 239 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 kstriped 248 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 ksnapd 259 root 10 -5 0 0 0 S 0.0 0.0 1:56.45 kjournald 281 root 10 -5 0 0 0 S 0.0 0.0 0:01.04 kauditd 309 root 16 -4 12632 744 408 S 0.0 0.0 0:00.37 udevd 636 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/0 637 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 kmpath_handlerd 656 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald 为了回答它，是的。
主要指标是CPU上53.2%等待时间。 如果您的I / O等待百分比大于（1个CPU核心数量），那么您的CPU正在等待磁盘子系统赶上的大量时间。
插入创build磁盘写入I / O，这通常是硬盘驱动器子系统的虚拟磁盘最糟糕的types。 硬盘在写作上比读书慢得多。 SSD的这种差距减小了，但写入时间仍然比读取时间慢。 因此，任何写操作都会产生比读操作更多的负面影响。
另外，将大负荷的大型数据库和/或数据库与不是针对繁重I / Odevise的磁盘sybsystem混合在一起，并且已经经历了大量I / O（如虚拟机的磁盘子系统），它会使问题倍增并造成主要的磁盘I / O问题。
将服务器移动到一个专用的磁盘子系统专门的盒子（这将是你的长期解决scheme），你最好的select是从虚拟机（如networking服务器）中取消任何不必要的负载，只需运行它的裸骨和SQL。 此外，请确保您正在调整您的索引和查询，并尽可能在非高峰时间尝试运行大部分插入查询。
是的，你是正确的，你有一个磁盘I / O问题。 顺便说一句，你为什么使用innodb_flush_log_at_trx_commit=1 ？ 在负载较重的环境下效果不佳，build议使用innodb_flush_log_at_trx_commit=2 。 但我不认为这会帮助你，因为你有大的插入，所以我假设交易率不是太高（不是每秒数百）。 所以你应该考虑通过添加更多的主轴来改善你的磁盘子系统。
只是作为一个逆向分析者，我不得不不同意一些分析。 首先，我认为艾奥瓦时间可能是非常具有误导性的。 所有这一切都是说CPU没有任何其他的东西。 换句话说，低iowait并不意味着磁盘不忙或者系统没有在等待，这意味着它有更好的事情要做，而不是等待io完成。
就我个人而言，我发现iostat输出的等待和服务时间更加丰富，即使我不是输出格式的粉丝，因为我发现阅读比collectl的输出要困难得多。 在任何情况下，输出的等待时间都只有20-40毫秒的数量级，其实并不是那么糟糕。
-标记