11

多くのマシン/ノードが関係する並行システムがあります。各マシンは、異なる処理を実行する複数のJVMを実行します。これは「階層化」アーキテクチャであり、各層はマシン間で実行される多数のJVMで構成されます。基本的に、最上位層のJVMは、ファイルを介して外部から入力を受け取り、入力を解析して、第2層の「ストレージ」用に同じ数の小さなレコードを送信します。レイヤー2は実際にはデータ自体を永続化しませんが、実際にはレイヤー3(HBaseとSolr)に永続化し、HBaseは永続化のためにレイヤー4(HDFS)に送信するため、実際にはデータ自体も永続化しません。

レイヤー間の通信のほとんどは同期されているため、もちろん、多くのスレッドが下位レイヤーの完了を待機することになります。しかし、これらの待機中のスレッドは、CPU使用率に対して「無料」であると期待しています。

ただし、非常に高いiowait(%waが上)が表示されます。これは、80〜90%のiowaitと10〜20%のsys /usrCPU使用率のようなものです。システムが使い果たされているようです-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 に答える