J'ai un problème avec Hadoop produisant trop de fichiers journaux en $ hadoop_log_dir / userlogs (le système de fichiers ext3 ne permet que 32 000 sous-répertoires) qui ressemble au même problème dans cette question: Erreur dans Hadoop Mapreduce
Ma question est la suivante: Est-ce que quelqu'un sait comment configurer Hadoop pour faire rouler le journal Dir ou l'empêcher d'éviter cela? J'essaie d'éviter de définir simplement le "Mapred.userlog.Retain.hours" et / ou "Mapred.userlog.limit.kb" Propriétés car je veux conserver les fichiers journaux.
J'espérais également configurer cela dans Log4J.properties, mais en regardant la source Hadoop 0.20.2, il écrit directement à des fichiers journaux au lieu d'utiliser le log4j. Peut-être que je ne comprends pas comment il utilise complètement log4J.
Toutes les suggestions ou clarifications seraient grandement appréciées.
5 Réponses :
Selon la documentation, Hadoop utilise log4j pour la journalisation . Peut-être que vous cherchez au mauvais endroit ...
Je vois que Hadoop inclut log4j, mais en regardant le code source, on dirait qu'il écrit directement au fichier journal au lieu d'utiliser Log4J correctement. Modification des propriétés Log4J Ne semble pas fonctionner à cause de cela.
@Eric Wendelin Pouvez-vous fournir un lien vers le fichier source où cela semble se produire?
J'ai eu ce même problème. Définissez la variable d'environnement "hadoop_root_logger = avertir, console" avant de démarrer Hadoop.
Pourriez-vous s'il vous plaît expliquer ce que cela fait? Est-ce que je perds quelque chose si je fais ça?
Malheureusement, lorsqu'il est présenté avec exactement le même problème, cette solution ne fonctionne pas. Il masque le niveau de sortie, mais n'empêche pas Hadoop d'écrire 32 000 sous-répertoires au dossier UserLogs de chaque nœud.
Configuration de Hadoop à utiliser log4J et paramètre décrit sur Cette page wiki ne fonctionne pas? regardant le Code source de connexion semble que Hadoop utilise la journalisation des communes de la communication, et il essaiera d'utiliser Log4J par défaut ou JDK Logger si log4j est pas sur la classe de classe. BTW, il est possible de changer les niveaux de journalisation au moment de l'exécution, jetez un coup d'œil à la Manuel des commandes .
Malheureusement, il n'y a pas de manière configurable pour empêcher cela. Chaque tâche d'un travail obtient un répertoire dans l'historique / UserLogs, qui conservera les fichiers STDOUT, STDERR et SYSLOG Task Sortie des tâches. Les heures de retenue aideront à garder trop de celles de l'accumulation, mais vous devez écrire un bon outil de rotation du journal pour les protéger automatiquement.
Nous avons également eu ce problème lorsque nous écrivions à un montage NFS, car tous les nœuds partagent le même répertoire historique / UserLogs. Cela signifie qu'un emploi avec 30 000 tâches suffirait à casser la FS. Loging localement est vraiment la voie à suivre lorsque votre cluster commence réellement à traiter de nombreuses données.
Si vous vous connectez déjà localement et que vous parvenez toujours à traiter 30 000 tâches sur une machine en moins d'une semaine, vous créez probablement trop de petits fichiers, ce qui provoque trop de mappeurs de se frayer une apparition pour chaque travail.
J'ai donc trouvé :) Notre solution consiste à modifier notre processus de collecte de données pour concaténer les fichiers avant d'exécuter des emplois.
J'ai également couru dans le même problème .... La ruche produise beaucoup de journaux et lorsque le nœud de disque est plein, aucun autre conteneur ne peut être lancé. En fil, il n'y a actuellement aucune option pour désactiver la journalisation. Un fichier particulièrement énorme est le fichier syslog, générant des ABS de journaux en quelques minutes dans notre cas.
Configuration de "Yarn-Site.xml" La propriété yarn.nodemanager.log.Retain-secondes à une petite valeur n'a pas d'aide . Réglage "Yarn.Nodemanager.log-DirS" à "Fichier: /// dev / null" n'est pas possible car un répertoire est nécessaire. Suppression de la ritght d'écriture (chmod -r / bûches) n'a pas fonctionné non plus.
Une solution pourrait être dans un répertoire "Null Blackhole". Vérifiez ici: https://unix.stackexchange.com/ QUESTIONS / 9332 / HOW-CAN-CARE-CREATE-A-Dev-Null-Like-Blackhole-Répertoire
Une autre solution travaillant pour nous est de désactiver le journal avant d'exécuter les travaux. Par exemple, dans la ruche, le démarrage du script par les lignes suivantes fonctionne: