11

我有一个涉及许多机器/节点的并发系统。每台机器运行几个 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
4

1 回答 1

2

Linux 上的 IO 等待表示进程在不间断 I/O 上被阻塞。在实践中,这通常意味着该进程正在执行磁盘访问——在这种情况下,我猜测以下之一:

  • hdfs 正在执行大量磁盘访问,结果导致其他磁盘访问变慢。(检查iostat -x可能会有所帮助,因为它会显示一个额外的“%util”列,指示磁盘“忙碌”的时间百分比。)
  • 您在负载下的系统内存不足,并且有时会陷入交换。
于 2012-02-22T07:36:13.503 回答