常にdfs.namenode.handler.countの構成パラメーター

Always Configuration Parameters Dfs

この記事の失敗は、バッチ方式を使用してDNノードを開始しましたが、HDFSメモリの再起動の問題の発生を回避しました。しかし、一時的な解決策であり、リスクは依然として存在します。したがって、これは基本的に不治の病を治します、私たちは他の構成パラメータから始めなければなりません。

最後に、ロック構成パラメーターdfs.namenode.handler.count。その解釈を見てみましょう
NameNodeには、クライアント呼び出しを処理するためのワーカースレッドのプールがあり、リモートプロシージャコールデーモンとクラスターがあります。処理手順の数が多いほど、異なるDataNodeからの同時ハートビートメタデータ操作とクライアントを同時に処理するためのプールが大きくなります。大規模なクラスターまたは多数のクライアントのクラスターの場合、通常はパラメーターを増やす必要がありますdfs.namenode.handler.countデフォルト値の10。一般原則の設定値は、自然数に20を掛けてクラスターサイズに設定されます。つまり、20logN、Nはクラスターのサイズです。
値の設定が小さすぎると、接続または接続がタイムアウトを拒否された場合は常にDataNode NameNodeになりますが、キューが大きい場合はNameNodeリモートプロシージャコールが発生し、リモートプロシージャコールの遅延が増加します。他の症状に影響を及ぼしているため、修正とは言い難いdfs.namenode.handler.count問題は解決しますが、トラブルシューティングの際には、この値の設定が必要であることを確認してください。

クラスター内で、このパラメーターはローカル保守担当者によって大幅に変更され、4000に達しました。つまり、スレッドプールを構成し、4000スレッドを収容できるため、メッセージング時に、ここでの情報量に対応することができます。メモリオーバーフローにつながります。したがって、この値を大きくすることはできますが、大きくしすぎることはできません。いくらですか？公式があります

python -c 'import math print int(math.log(N) * 20)' Cluster #N number of servers