Question

我有一个并发系统，涉及许多机器/节点。每台机器运行几个JVM做不同的东西。它是一个“分层”架构，每个层都包含许多运行在机器上的JVM。基本上，顶层JVM通过文件从外部接收输入，解析输入并在第二层中为“存储”发送尽可能多的小记录。第二层实际上并不保留数据本身，但实际上它仍然存在于第三层（HBase和Solr）中，并且HBase实际上并不会自行保留它，因为它将它发送到第四层（HDFS）以实现持久性。

层之间的大多数通信都是同步的，因此它当然会在很多线程中等待较低层完成。但我希望那些等待线程能够“免费”使用CPU。

我看到一个非常高的iowait（％wa在顶部） - 像80-90％的iowait和只有10-20％的sys / usr CPU使用率。系统似乎已经筋疲力尽 - 通过ssh登录速度慢，对命令响应速度慢等。

我的问题是，等待较低层完成的所有JVM线程是否会导致这种情况？它不应该是“免费”等待响应（套接字）。对此有关重要，不同的层是否使用阻塞或非阻塞（NIO）io？究竟在什么情况下Linux算作iowait（％wa在顶部）？当机器上所有JVM中的所有线程都处于等待状态时（因为在此期间没有其他线程可以运行以执行某些有意义的操作）？或者即使有其他进程准备好使用CPU进行实际处理，线程等待也会计入％wa？

我真的想要彻底解释它是如何工作的，以及如何解释这个高％wa。在开始时我猜想当所有线程都在等待时它会计为％wa，但实际上还有足够的空间来做更多，所以我试图增加线程数量，期望获得更多的吞吐量，但这不会发生。所以这是一个真正的问题，而不仅仅是看到顶部的“视觉”问题。

以下输出取自仅运行HBase和HDFS的计算机。它是在HBase和/或HDFS的机器上显示的问题（最清楚）

--- jps ---
19498 DataNode
19690 HRegionServer
19327 SecondaryNameNode

---- typical top -------
top - 11:13:21 up 14 days, 18:20,  1 user,  load average: 4.83, 4.50, 4.25
Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 14.1%us,  4.3%sy,  0.0%ni,  5.4%id, 74.8%wa,  0.0%hi,  1.3%si,  0.0%st
Mem:   7133800k total,  7099632k used,    34168k free,    55540k buffers
Swap:   487416k total,      248k used,   487168k free,  2076804k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM TIME+
COMMAND
19690 hbase     20   0 4629m 4.2g 9244 S   51 61.7 194:08.84 java
19498 hdfs      20   0 1030m 116m 9076 S   16  1.7  75:29.26 java

---- iostat -kd 1 ----
root@edrxen1-2:~# iostat -kd 1
Linux 2.6.32-29-server (edrxen1-2)      02/22/2012      _x86_64_        (2 CPU)
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              3.53         3.36        15.66    4279502   19973226
dm-0            319.44      6959.14       422.37 8876213913  538720280
dm-1              0.00         0.00         0.00        912        624
xvdb            229.03      6955.81       406.71 8871957888  518747772
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0
dm-0            122.00      3852.00         0.00       3852          0
dm-1              0.00         0.00         0.00          0          0
xvdb            105.00      3252.00         0.00       3252          0
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0
dm-0             57.00      1712.00         0.00       1712          0
dm-1              0.00         0.00         0.00          0          0
xvdb             78.00      2428.00         0.00       2428          0

--- iostat -x ---
Linux 2.6.32-29-server (edrxen1-2)      02/22/2012      _x86_64_        (2 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.06    0.00    3.29   65.14    0.08   23.43
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
xvda              0.00     0.74    0.35    3.18     6.72    31.32    10.78     0.11   30.28   6.24   2.20
dm-0              0.00     0.00  213.15  106.59 13866.95   852.73    46.04     1.29   14.41   2.83  90.58
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    5.78   1.12   0.00
xvdb              0.07    86.97  212.73   15.69 13860.27   821.42    64.27     2.44   25.21   3.96  90.47

--- free -o ----
             total       used       free     shared    buffers     cached
Mem:       7133800    7099452      34348          0      55612    2082364
Swap:       487416        248     487168

Answer 1

Linux上的IO等待表示进程在不间断I / O上被阻止。实际上，它通常意味着进程正在执行磁盘访问 - 在这种情况下，我猜是以下之一：

hdfs执行大量磁盘访问，结果导致其他磁盘访问速度变慢。（检查iostat -x可能有所帮助，因为它会显示一个额外的“％util”列，表示磁盘“忙”的时间百分比。）
您在负载下的系统内存不足，最终有时会进入交换。

在Linux上使用java进程的高iowait

1 个答案: