Почему фаза карты TeraSort тратит значительное время в функции CRC32.update ()? - PullRequest
Новая
       11

Почему фаза карты TeraSort тратит значительное время в функции CRC32.update ()?

2 голосов
/ 18 августа 2011

Я пытаюсь профилировать, какие функции занимают больше всего времени для задания TeraSort Hadoop.для моей тестовой системы я использую базовую псевдораспределенную установку с 1 узлом.Это означает, что все JVM NameNode, DataNode, Tasktracker и Jobtracker работают на одном компьютере.

Сначала я генерирую ~ 9 ГБ данных с помощью TeraGen, а затем запускаю на нем TeraSort.Пока выполняются JVM, я проверяю их выполнение с помощью VisualVM.Я знаю, что это не самый точный профилировщик, но он бесплатный и простой в использовании!Я использую последнюю версию дистрибутива Apache hadoop, и мои эксперименты проводятся на системе на базе Intel Atom.

Когда я смотрю на Self time (CPU) для Hot Spots-Methods в VisualVM, я вижу java.Функция util.zip.CRC32.update () занимает почти 40% общего времени.Когда я смотрю на эту функцию в дереве вызовов, она вызывается функцией main () маппера, особенно когда IdentityMapper.map () читает входные файлы из HDFS.Функция, которая фактически выполняет вызов функции CRC32.update (): org.apache.hadoop.fs.FSInputChecker.readChecksumChunk ()

У меня есть три вопроса по этому поводу:

  1. Почему контрольная сумма CRC32 обновляется для блоков, считываемых из HDFS?Если я правильно понимаю, как только блок прочитан, простое сравнение данных, считанных с диска, с CRC блока должно быть единственной операцией, а не генерировать и обновлять значение CRC блока.

  2. Я искал источник для функции обновления, и она реализована в файле java.util.zip.CRC32.java.Конкретная вызываемая функция - это перегруженный метод update () с тремя аргументами.Поскольку эта функция реализована в Java, возможно ли, что несколько уровней абстракции (Hadoop, JVM, инструкции процессора) снижают собственную эффективность вычисления CRC?

  3. Наконец, есть ли что-тосовершенно неправильно с моей методологией VisualVM или интерпретацией результатов выборки?

Спасибо,

1 Ответ

0 голосов
/ 16 января 2014

На ваш первый вопрос, я думаю, ответ заключается в том, что файлы CRC имеют реплики и могут быть повреждены.Например, предположим, что у нас есть набор файлов / каталогов с коэффициентом репликации 2, тогда могут произойти следующие сценарии, и CRC потребуется пересчитать и обновить:

  1. Удалить метафайл на одной реплике
  2. Усекает метафайл в одной реплике
  3. Корректирует заголовок метафайла в одной реплике
  4. Корректирует любое случайное смещение и часть метафайла
  5. Меняет местами два метафайлаформат метафайлов действителен, но их CRC не совпадают с соответствующими им блоками данных

Если вы посмотрите на проблемы JIRA для Hadoop Common, вы можете найти много проблем, связанных сПовреждение CRC.

По второму вопросу, не могли бы вы сказать, какую версию Hadoop вы используете?Эффективность CRC неоднократно жаловалась и повышалась.

...