top 命令的 wa(等待 I/O)很大

top 命令的 wa(等待 I/O)很大

我有一个论坛,有很多访客,有些日子,负载增加到 40,而访客数量却没有增加。从下面的输出中可以看出,等待时间很长 (57%)。我该如何找到原因呢?
服务器软件是Apache、MySQL和PHP。

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

答案1

以下是一些查找磁盘活动的工具:

  • iotop
  • vmstat 1
  • iostat 1
  • lsof
  • strace -e trace=open <application>
  • strace -e trace=open -p <pid>

ps auxf还将看到哪些进程处于不间断磁盘睡眠状态(D),因为它们正在等待 I/O。

有时候,访问量会增加到 40,但访问者数量并没有增加。

您可能还想创建备份,看看硬盘是否正在慢慢出现故障。硬盘通常在损坏之前就开始变慢。这也可以解释高负载的原因。

答案2

顶部的输出表明 DBMS 正在经历大多数 I/O 等待,因此数据库调整问题显然是需要调查的。

数据库服务器上的 I/O 等待(尤其是在负载高峰时)表明您的 DBMS 可能受磁盘限制(即您需要更快的磁盘子系统)或可能存在调优问题。您可能还应该研究数据库服务器的配置 - 即跟踪它正在做什么以及哪些查询占用了时间。

诊断数据库调整问题的一些起点:

  • 找到耗时最多的查询,并查看查询计划。查看是否有奇怪的查询计划,例如不应该出现的表扫描。也许数据库需要添加索引。

  • 较长的资源等待时间可能意味着某些关键资源池需要扩展。

  • 较长的 I/O 等待时间可能意味着您需要更快的磁盘子系统。

  • 您的日志和数据卷是否位于不同的驱动器上?数据库日志有很多小的连续写入(本质上它们的行为类似于环形缓冲区)。如果您有一个繁忙的随机访问工作负载与您的日志共享同一个磁盘,这将严重影响日志的吞吐量。要提交数据库事务,必须将日志条目写入磁盘,因此这会对整个系统造成瓶颈。

    请注意,某些 MySQL 存储引擎不使用日志,因此这对您来说可能不是问题。

脚注:排队系统

排队系统(吞吐量的统计模型)在系统接近饱和时会以双曲线方式变慢。对于高水平近似,饱和度为 50% 的系统的平均队列长度为 2。饱和度为 90% 的系统队列长度为 10,饱和度为 99% 的系统队列长度为 100。

因此,在接近饱和的系统中,负载的微小变化可能会导致等待时间发生很大变化,在这种情况下表现为等待 I/O 的时间。如果磁盘子系统的 I/O 容量接近饱和,则负载的微小变化可能会导致响应时间发生重大变化。

答案3

运行iotopatop -dD,查看哪些进程正在执行 io。strace如果您需要仔细查看,请使用。

答案4

有时候,访问量会增加到 40,但访问者数量并没有增加。

用户正在做什么可能与实际用户数量一样重要。搜索论坛等操作将比加载和查看单个主题或主题列表更加费力。

另外:您是在专用服务器还是 VPS 上运行?如果您的服务不在专用服务器上,那么在同一主机上运行的应用程序的操作将产生影响,因为与您的 VM 共享主机的 VM 将争夺 I/O 资源的份额。

正如其他人指出的那样,像这样的工具iotop将帮助您更深入地了解哪些任务正在等待 I/O 响应以及它们当时正在访问哪些文件。

相关内容