Home/ Questions/Q 1032843
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T14:08:34+00:00

I’m having a problem with Hadoop producing too many log files in $HADOOP_LOG_DIR/userlogs (the

  • 0

I’m having a problem with Hadoop producing too many log files in $HADOOP_LOG_DIR/userlogs (the Ext3 filesystem allows only 32000 subdirectories) which looks like the same problem in this question: Error in Hadoop MapReduce

My question is: does anyone know how to configure Hadoop to roll the log dir or otherwise prevent this? I’m trying to avoid just setting the “mapred.userlog.retain.hours” and/or “mapred.userlog.limit.kb” properties because I want to actually keep the log files.

I was also hoping to configure this in log4j.properties, but looking at the Hadoop 0.20.2 source, it writes directly to logfiles instead of actually using log4j. Perhaps I don’t understand how it’s using log4j fully.

Any suggestions or clarifications would be greatly appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Unfortunately, there isn’t a configurable way to prevent that. Every task for a job gets one directory in history/userlogs, which will hold the stdout, stderr, and syslog task log output files. The retain hours will help keep too many of those from accumulating, but you’d have to write a good log rotation tool to auto-tar them.

    We had this problem too when we were writing to an NFS mount, because all nodes would share the same history/userlogs directory. This means one job with 30,000 tasks would be enough to break the FS. Logging locally is really the way to go when your cluster actually starts processing a lot of data.

    If you are already logging locally and still manage to process 30,000+ tasks on one machine in less than a week, then you are probably creating too many small files, causing too many mappers to spawn for each job.

    • 0