2016-10-05 1 views
0

Nous avons récemment décidé d'activer la journalisation GC pour Hadoop MapReduce2 History Server sur un certain nombre de clusters (version exacte varie). regarder dans la mémoire liée à l'histoire-serveur et les problèmes de récupération de place. Tout en faisant cela, nous voulons éviter deux problèmes que nous connaissons pourrait arriver:Comment activer la journalisation GC pour Hadoop MapReduce2 History Server, tout en évitant l'écrasement des fichiers journaux et l'utilisation de l'espace disque

  • écrasement du fichier journal lorsque le serveur redémarre Histoire MR2 pour quelque raison que ce
  • les journaux en utilisant l'espace disque trop, conduisant à des disques obtenir rempli

Lorsque la journalisation Java GC démarre pour un processus, elle semble remplacer le contenu de tout fichier portant le même nom. Cela signifie qu'à moins d'être prudent, vous perdrez la journalisation GC, peut-être lorsque vous en aurez le plus besoin.

Si vous conservez suffisamment longtemps le cluster, les fichiers journaux rempliront le disque à moins d'être gérés. Même si la journalisation GC n'est pas actuellement volumineuse, nous voulons gérer le risque d'une situation inhabituelle qui entraîne une augmentation soudaine du taux d'enregistrement.

Répondre

0

Vous devrez définir certains paramètres JVM lors du démarrage de MapReduce2 History Server, ce qui signifie que vous devez apporter des modifications à mapred-env.sh. Vous pouvez définir les paramètres dans HADOOP_OPTS, mais cela aura un impact plus large que le seul serveur History, vous préférerez probablement les définir dans HADOOP_JOB_HISTORYSERVER_OPTS.

Passons maintenant aux paramètres JVM à inclure dans ceux-ci.

Pour activer la journalisation GC dans un fichier, vous devez ajouter -verbose:gc -Xloggc:<log-file-location>.

Vous devez accorder une attention particulière au nom du fichier journal pour éviter les écrasements lors du redémarrage du serveur. Il semble que vous ayez besoin d'un nom unique pour chaque invocation, donc l'ajout d'un horodatage semble être la meilleure option. Vous pouvez inclure quelque chose comme "date +"% Y% m% d% H% M'` pour ajouter un horodatage. Dans cet exemple, il est sous la forme de YYYYMMDDHHMM. Dans certaines versions de Java, vous pouvez mettre "% t" dans votre emplacement de fichier journal et il sera remplacé par l'horodateur de démarrage du serveur au format AAAA-MM-JJ_HH-MM-SS.

Maintenant sur la gestion de l'utilisation de l'espace disque. Je serai heureux s'il y a un moyen plus simple que ce que j'ai. Tout d'abord, profitez de la rotation intégrée du fichier journal GC de Java. -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M est un exemple d'activation de cette rotation, avec jusqu'à 10 fichiers journaux GC provenant de la machine virtuelle Java, dont chacun ne fait pas plus de 10 Mo environ. 10 x 10 Mo est 100 Mo d'utilisation maximale. Avec la rotation du fichier journal GC en place avec jusqu'à 10 fichiers, '.0', '.1', ... '.9' sera ajouté au nom de fichier que vous avez donné en Xloggc. .0 sera le premier et après il atteindra .9 il remplacera .0 et continuera sur un tournoi à la ronde. Dans certaines versions de Java, '.current' sera ajouté à la fin du nom du fichier journal en cours d'écriture.

En raison du fichier unique de nommage, nous avons apparemment devoir éviter les écrasements, vous pouvez avoir 100 Mo par appel du serveur d'histoire, donc ce n'est pas une solution complète pour la gestion de l'espace disque utilisé par les journaux de GC du serveur. Vous vous retrouverez avec un jeu de 10 fichiers journaux GC au maximum sur chaque appel de serveur - cela peut s'accumuler avec le temps. La meilleure solution (sous * nix) à cela semble être d'utiliser l'utilitaire logrotate (ou un autre utilitaire) pour nettoyer périodiquement les logs du GC qui n'ont pas été modifiés au cours des N derniers jours.

Assurez-vous de faire le calcul et assurez-vous que vous aurez suffisamment d'espace disque.

Les gens veulent souvent plus de détails et de contexte dans leurs journaux GC que les valeurs par défaut, alors pensez à ajouter -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps.

Mettre cela ensemble, vous pouvez ajouter quelque chose à ce mapred-env:

## enable GC logging for MR2 History Server: 

TIMESTAMP=`date +'%Y%m%d%H%M'` 
# GC log location/name prior to .n addition by log rotation 
JOB_HISTORYSERVER_GC_LOG_NAME="{{mapred_log_dir_prefix}}/$USER/mapred-jobhistory-gc.log-$TIMESTAMP" 

JOB_HISTORYSERVER_GC_LOG_ENABLE_OPTS="-verbose:gc -Xloggc:$JOB_HISTORYSERVER_GC_LOG_NAME" 
JOB_HISTORYSERVER_GC_LOG_ROTATION_OPTS="-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M" 
JOB_HISTORYSERVER_GC_LOG_FORMAT_OPTS="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps" 

JOB_HISTORYSERVER_GC_LOG_OPTS="$JOB_HISTORYSERVER_GC_LOG_ENABLE_OPTS $JOB_HISTORYSERVER_GC_LOG_ROTATION_OPTS $JOB_HISTORYSERVER_GC_LOG_FORMAT_OPTS" 
export HADOOP_JOB_HISTORYSERVER_OPTS="$HADOOP_JOB_HISTORYSERVER_OPTS $JOB_HISTORYSERVER_GC_LOG_OPTS" 

Vous trouverez peut-être que vous avez déjà une référence à HADOOP_JOB_HISTORYSERVER_OPTS de sorte que vous devez remplacer ou ajouter sur cela. Dans ce qui précède, vous pouvez modifier {{mapred_log_dir_prefix}}/$USER à l'endroit où vous voulez que les journaux du GC disparaissent (vous voulez probablement qu'il se retrouve au même endroit que les journaux du serveur d'historique de MapReduce). Vous pouvez également modifier le nom du fichier journal.

Si vous gérez votre cluster Hadoop avec Apache Ambari, ces modifications se trouvent dans le service MapReduce2> Configs> Avancé> Mapred-env avancé> Mapred-env. Avec Ambari, {{mapred_log_dir_prefix}} sera automatiquement remplacé par le préfixe Mapreduce Log Dir défini à quelques lignes au-dessus du champ.

La consignation par GC commencera à se produire lorsque le serveur redémarrera le serveur. Vous devrez peut-être effectuer une courte interruption pour activer cette fonction.