TeraSort Hadoop ジョブで最も多くの時間を消費する関数をプロファイリングしようとしています。私のテスト システムでは、基本的な 1 ノードの疑似分散セットアップを使用しています。これは、NameNode、DataNode、Tasktracker、および Jobtracker JVM がすべて同じマシンで実行されることを意味します。
最初に TeraGen を使用して ~9GB のデータを生成し、次に TeraSort を実行します。JVM が実行されている間、VisualVM を使用してその実行をサンプリングします。これが最も正確なプロファイラーではないことはわかっていますが、無料で使いやすいです! 私は最新バージョンの Apache Hadoop ディストリビューションを使用しており、私の実験は Intel Atom ベースのシステムで実行されています。
VisualVM のホット スポット メソッドのセルフ タイム (CPU) を見ると、java.util.zip.CRC32.update() 関数が合計時間の約 40% を占めていることがわかります。コール ツリーでこの関数を見ると、特に IdentityMapper.map() が HDFS から入力ファイルを読み取っているときに、マッパーの main() 関数によって呼び出されます。CRC32.update() 関数を実際に呼び出す関数は、org.apache.hadoop.fs.FSInputChecker.readChecksumChunk() です。
これに関して 3 つの質問があります。
HDFS から読み取られるブロックの CRC32 チェックサムが更新されるのはなぜですか? 私が正しく理解している場合、ブロックが読み取られると、ブロックのCRC値を生成および更新するのではなく、ディスクから読み取られたデータとブロックのCRCとの単純な比較が唯一の操作になるはずです。
update 関数のソースを調べたところ、java.util.zip.CRC32.java ファイルによって実装されています。呼び出される特定の関数は、3 つの引数を持つオーバーロードされた update() メソッドです。この関数は Java で実装されているため、複数の抽象化レイヤー (Hadoop、JVM、CPU 命令) が CRC 計算のネイティブ効率を低下させている可能性はありますか?
最後に、私の VisualVM 計測方法、またはサンプリング結果の解釈に重大な問題がありますか?
ありがとう、