Настройка ведения журнала Hadoop, чтобы избежать слишком большого количества файлов журнала - PullRequest
Новая
       13

Настройка ведения журнала Hadoop, чтобы избежать слишком большого количества файлов журнала

11 голосов
/ 17 апреля 2010

У меня проблема с Hadoop, производящим слишком много файлов журналов в $ HADOOP_LOG_DIR / userlogs (файловая система Ext3 допускает только 32000 подкаталогов), что похоже на ту же проблему в этом вопросе: Ошибка в Hadoop MapReduce

У меня вопрос: кто-нибудь знает, как настроить Hadoop, чтобы он катил журнал, или как-то иначе это предотвратить? Я пытаюсь избежать установки свойств "mapred.userlog.retain.hours" и / или "mapred.userlog.limit.kb", потому что я хочу сохранить файлы журнала.

Я также надеялся настроить это в log4j.properties, но, глядя на источник Hadoop 0.20.2, он пишет напрямую в лог-файлы вместо того, чтобы фактически использовать log4j. Возможно, я не понимаю, как он полностью использует log4j.

Любые предложения или разъяснения будут с благодарностью.

Ответы [ 5 ]

5 голосов
/ 28 апреля 2010

У меня была такая же проблема. Установите переменную среды "HADOOP_ROOT_LOGGER = WARN, console" перед запуском Hadoop. 

export HADOOP_ROOT_LOGGER="WARN,console"
hadoop jar start.jar
4 голосов
/ 25 августа 2010

К сожалению, нет настраиваемого способа предотвратить это. Каждое задание для задания получает один каталог в history / userlogs, в котором будут храниться выходные файлы журнала задач stdout, stderr и syslog. Время хранения поможет предотвратить накопление слишком многих из них, но вам придется написать хороший инструмент ротации журналов, чтобы автоматически их изменять.

У нас тоже была эта проблема при записи в монтирование NFS, потому что все узлы имели бы общий каталог history / userlogs. Это означает, что одной работы с 30000 задач будет достаточно, чтобы сломать FS. Локальное ведение журнала - это действительно тот путь, когда ваш кластер фактически начинает обрабатывать много данных.

Если вы уже регистрируетесь локально и по-прежнему можете обрабатывать более 30 000 задач на одном компьютере менее чем за неделю, то вы, вероятно, создаете слишком много небольших файлов, что приводит к появлению слишком большого числа сопоставителей для каждой работы.

2 голосов
/ 29 апреля 2010

Настройка hadoop для использования log4j и настройка 

log4j.appender.FILE_AP1.MaxFileSize=100MB
log4j.appender.FILE_AP1.MaxBackupIndex=10

как описано на эта вики-страница не работает?

Глядя на исходный код LogLevel , кажется, что hadoop использует ведение журналов общего доступа, и он попытается использовать log4j по умолчанию или jdk logger, если log4j не находится в пути к классам.

Кстати, можно изменить уровни журнала во время выполнения, взгляните на руководство по командам .

1 голос
/ 17 апреля 2010

Согласно документации, Hadoop использует log4j для регистрации . Может быть, вы ищете не в том месте ...

0 голосов
/ 19 сентября 2015

Я также столкнулся с той же проблемой .... Hive создает много журналов, и когда узел диска заполнен, больше контейнеров не может быть запущено. В Yarn в настоящее время нет возможности отключить ведение журнала. Один файл, особенно большой, это файл системного журнала, в нашем случае генерирующий ГБ журналов за несколько минут.

Настройка в "yarn-site.xml" свойства yarn.nodemanager.log.retain-секунд на небольшое значение не помогает. Установка для "yarn.nodemanager.log-dirs" значения "file: /// dev / null" невозможна, поскольку требуется каталог. Удаление записи (chmod -r / logs) также не сработало.

Одним из решений может быть каталог "null blackhole". Проверьте здесь: https://unix.stackexchange.com/questions/9332/how-can-i-create-a-dev-null-like-blackhole-directory

Другое решение, которое работает для нас, - отключить журнал перед запуском заданий. Например, в Hive работает запуск скрипта следующими строками: 

set yarn.app.mapreduce.am.log.level=OFF;
set mapreduce.map.log.level=OFF;
set mapreduce.reduce.log.level=OFF;
...