单个目录中的Ubuntu 16.04.5 LTS慢磁盘IO

时间:2019-01-31 23:28:01

标签: ubuntu nginx io read-write

我有一台运行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 /目录中的某个地方尝试相同的文件传输来进行复制。

如果需要,我可以提供更多信息。

1 个答案:

答案 0 :(得分:0)

在挖掘和挖掘之后,我发现了。事实证明,该目录实际上是AWS弹性文件系统的安装点。我继承了这个从旧的系统管理员谁在所有关于它没有留下任何文档。

因此,瓶颈根本不是性能I / O。它是从AWS文件系统读取/写入的。