我有一台运行Ubuntu 16.04.5 LTS的AWS服务器,该服务器在写入目录时具有超慢的I / O。网络服务器在单个SSD分区上运行Nginx 1.14.1和php7.0-fpm:
root@ip-10-0-5-223:/home/ubuntu# sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME FSTYPE SIZE MOUNTPOINT LABEL
xvda 100G
└─xvda1 ext4 100G / cloudimg-rootfs
当写入我的/ var / web(/ var / www更常用)时,与其他目录相比,我的磁盘IO非常慢。如果我将全新的Wordpress安装复制到/ home /或/ var /中任何位置的目录中,我的IO速度将非常快并且仅占用很少的CPU和内存。
top - 23:03:18 up 1 day, 7:54, 2 users, load average: 0.52, 0.63, 0.71
Tasks: 163 total, 2 running, 161 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.4 us, 0.7 sy, 0.0 ni, 96.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.1 st
KiB Mem : 16430960 total, 13827148 free, 336940 used, 2266872 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 15644724 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11209 www-data 20 0 512832 113412 73056 S 6.3 0.7 0:39.47 php-fpm7.0
11990 www-data 20 0 814560 109252 70616 R 3.3 0.7 0:13.13 php-fpm7.0
11993 www-data 20 0 489944 91344 73772 S 0.7 0.6 0:14.54 php-fpm7.0
11994 www-data 20 0 805180 112676 83184 S 0.7 0.7 0:12.00 php-fpm7.0
12348 root 0 -20 0 0 0 S 0.7 0.0 0:01.26 kworker/3:1H
11988 root 0 -20 0 0 0 S 0.3 0.0 0:00.91 kworker/2:0H
1 root 20 0 119732 5320 3440 S 0.0 0.0 0:06.64 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.41 ksoftirqd/0
7 root 20 0 0 0 0 S 0.0 0.0 1:52.96 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.04 migration/0
10 root rt 0 0 0 0 S 0.0 0.0 0:00.26 watchdog/0
11 root rt 0 0 0 0 S 0.0 0.0 0:00.22 watchdog/
磁盘的读写速度是如此之快,以至于我什至无法在dstat中捕捉它们。
但是,当我写入/ var / web /目录中的任何内容时,我的CPU等待时间非常慢,大约需要30秒才能完成该过程。
Tasks: 160 total, 1 running, 159 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.5 us, 0.5 sy, 0.0 ni, 83.4 id, 13.4 wa, 0.0 hi, 0.1 si, 0.1 st
KiB Mem : 16430960 total, 13828044 free, 363464 used, 2239452 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 15618252 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11211 www-data 20 0 818068 125568 83196 S 9.0 0.8 0:49.70 php-fpm7.0
11987 www-data 20 0 495908 98248 74900 S 3.0 0.6 0:29.39 php-fpm7.0
13120 root 0 -20 0 0 0 S 1.0 0.0 0:02.01 kworker/3:2H
11990 www-data 20 0 797912 103656 82520 S 0.7 0.6 0:25.98 php-fpm7.0
13218 root 20 0 20232 2492 2332 D 0.7 0.0 0:00.06 cp
3886 www-data 20 0 257088 18612 5368 S 0.3 0.1 0:29.71 nginx
11992 root 0 -20 0 0 0 S 0.3 0.0 0:02.37 kworker/1:0H
1 root 20 0 119732 5320 3440 S 0.0 0.0 0:06.68 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.42 ksoftirqd/0
7 root 20 0 0 0 0 S 0.0 0.0 1:53.83 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.04 migration/0
这是dstat报告:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
3 1 96 1 0 0| 529k 790k| 0 0 | 0 0 |3686 3416
1 0 99 0 0 0| 0 24k| 36k 32k| 0 0 | 426 336
2 1 95 3 0 0| 0 0 | 217k 224k| 0 0 |2359 2508
3 1 84 12 0 0| 0 0 | 284k 544k| 0 0 |4421 4629
2 1 85 13 0 0| 16k 0 | 231k 637k| 0 0 |3613 3562
0 0 85 14 0 0| 0 0 | 58k 729k| 0 0 |1044 1133
0 0 87 13 0 0| 0 0 | 64k 391k| 0 0 |1238 1307
0 0 87 13 0 0| 0 80k| 63k 567k| 0 0 |1193 1272
0 0 86 14 0 0| 0 0 | 62k 623k| 0 0 |1190 1249
4 1 84 12 0 0| 0 16k| 251k 575k| 0 0 |1797 1771
2 0 85 13 0 0| 0 0 | 110k 1024k| 0 0 |1407 1235
0 0 86 14 0 0| 0 0 | 60k 739k| 0 0 |1199 1204
0 0 86 14 0 0| 0 0 | 61k 627k| 0 0 |1156 1208
4 1 84 12 0 0| 0 0 | 227k 426k| 0 0 |2015 1760
0 0 87 13 0 0| 0 96k| 67k 502k| 0 0 |1261 1350
1 0 85 14 0 0| 0 0 | 80k 947k| 0 0 |1219 1272
0 0 88 12 0 0| 0 0 | 70k 558k| 0 0 |1305 1380
1 0 88 11 0 0| 0 0 | 87k 665k| 0 0 |1516 1515
2 1 87 10 0 0| 0 0 | 152k 290k| 0 0 |1883 1753
0 1 87 12 0 0| 0 0 | 68k 890k| 0 0 |1272 1354
0 0 88 11 0 0| 0 0 | 71k 353k| 0 0 |1224 1413
4 0 83 13 0 0| 0 24k| 216k 1258k| 0 0 |1766 1589
1 0 88 12 0 0| 0 0 | 84k 444k| 0 0 |1392 1471
1 1 88 10 0 0| 0 0 | 109k 189k| 0 0 |1641 1662
该特定目录非常大,因为它包含许多网站。难道这就是全部吗?某些事情占用了一部分CPU,并确实增加了这些CPU等待时间,但是我可以通过在/ var /目录中的某个地方尝试相同的文件传输来进行复制。
如果需要,我可以提供更多信息。
答案 0 :(得分:0)
在挖掘和挖掘之后,我发现了。事实证明,该目录实际上是AWS弹性文件系统的安装点。我继承了这个从旧的系统管理员谁在所有关于它没有留下任何文档。
因此,瓶颈根本不是性能I / O。它是从AWS文件系统读取/写入的。