Hadoopクラスター内で利用可能なファイル記述子の管理
私は現在、雇用主のために急速に成長しているHadoopクラスターを担当しています。現在、リリース0.21.0に基づいて構築されており、各ワーカーとマスターノードのOSとしてCentOSを使用しています。私はほとんどの標準構成の問題（負荷分散、IO HDFSの計画、スピル操作に十分なディスク容量を確保するなど））に取り組みましたが、うまくいきませんでした。各タスクトラッカー、データノード、マッパー、またはレデューサーに必要なファイル記述子の数の管理に関するドキュメント。
私がこれまでに読んだドキュメント（HadoopとHBase全体）は、ディスクに書き込もうとしたときに同時に多数の記述子を消費するスピル操作を漠然と指摘しています。もちろん、このドキュメントは、前述の記述子の範囲または予想される存続期間の内訳を提供しません。与えられた唯一の提案は、システム制限を引き上げることでした。これは、回避策としてもっともらしく、長期計画の戦略としては偽りです。
必要なファイル記述子の数に関してHadoopがどのような仮定をしているのかについての情報はありません。その結果、通常のジョブの存続期間中（つまり、MultipleOutputsに依存しない）にマッパー、レデューサー、タスクトラッカー、およびデータノードごとに必要なファイル記述子の総数を構成に依存して計算すると非常に便利です。
そのような計算は現在存在しますか？もしそうなら、定義された任意の数のジョブに対して私の制限がどうあるべきかについて合理的な見積もりをすることができますか？
（この質問がこの問題を経験している他の人によって発見される可能性を高めるために、Hadoopは、使用可能な記述子のプールが使い果たされたときにJava.io.EOFExceptionとJava.io.IOException（不正なファイル記述子を指す）を喜んでスローします。これこれらの例外に含まれるメッセージは非常に一般的であるため、追跡するのに数時間かかりました。）
これはHadoopエコシステムの問題の主な原因であり、AFAIKには、この種のリソースの包括的な計画に対する適切な答えがありません。全体として、これは、システムに適用している称賛に値するレベルの注意をサポートするエンタープライズ品質のHadoopディストリビューションではありません。
ただし、今後数か月以内に1つになると確信しています。