Aller au contenu

Traitement parallèle

Choisissez entre le découpage parallèle d’un seul journal et le traitement parallèle de plusieurs journaux

pgBadger dispose de deux modes de traitement parallèle complémentaires. Choisissez selon la structure des données d’entrée, et non simplement selon le nombre de processeurs.

Option Unité parallèle Cas adapté Contrainte principale
-j N / --jobs N tronçons d’un fichier journal un seul fichier journal volumineux et permettant un accès direct aux positions dans le fichier les limites des tronçons peuvent dupliquer ou omettre un petit nombre de requêtes
-J N / --Jobs N fichiers journaux entiers plusieurs fichiers journaux indépendants utile uniquement lorsque suffisamment de fichiers sont disponibles pour occuper les processus de travail

Découper un grand fichier avec -j

$ pgbadger -j 8 /var/log/postgresql/postgresql.log

L’algorithme du projet amont divise chaque fichier en N plages d’octets, lance un parseur par plage, écrit des statistiques binaires temporaires, puis fusionne ces statistiques pour produire le rapport final.

pour chaque fichier journal
    diviser le fichier en N tronçons
    trouver les positions de début et de fin de chaque tronçon
    créer N processus d’analyse à ces positions
    écrire un fichier temporaire de statistiques binaires par processus
attendre la fin des processus de travail
fusionner les fichiers binaires et générer le rapport

Étant donné que les enregistrements de journal et les requêtes multilignes ne correspondent pas parfaitement aux décalages d’octets, jusqu’à environ N requêtes par fichier peuvent être tronquées, omises ou, plus fréquemment, comptées deux fois aux limites des tronçons. Utilisez ce mode pour une analyse agrégée de fichiers très volumineux, et non pour un flux de travail nécessitant un décompte précis de chaque enregistrement.

Traiter plusieurs fichiers avec -J

$ pgbadger -J 8 /var/log/postgresql/postgresql-*.log

Chaque processus de travail traite un fichier complet, ce qui permet d’éviter les lacunes aux limites des tronçons. Ce mode devient particulièrement utile avec des centaines de petits fichiers et une capacité CPU et E/S suffisante. La documentation officielle autorise également -J pour des fichiers compressés indépendants ; le découpage en tronçons sur un seul fichier avec -j nécessite une entrée permettant un accès direct aux positions dans le fichier, non compressée.

Benchmark du projet amont

Le manuel du projet amont indique ces mesures sur un hôte à 8 processeurs. Considérez-les comme une comparaison entre les deux algorithmes, et non comme une prédiction pour le matériel actuel.

Un fichier de 9,5 Go :

Option 1 CPU 2 CPU 4 CPU 8 CPU
-j 1h41m18 50m25 25m39 15m58
-J 1h41m18 54m28 41m16 34m45

Deux cents fichiers de 10 Mo, soit 2 Go au total :

Option 1 CPU 2 CPU 4 CPU 8 CPU
-j 20m15 9m56 5m20 4m20
-J 20m15 9m49 5m00 2m40

En pratique, privilégiez -j pour quelques fichiers volumineux et -J pour de nombreux petits fichiers. Les deux modes peuvent être combinés lorsque l’entrée et la plateforme le permettent, mais testez cette combinaison : l’analyse des journaux peut devenir limitée par le débit de stockage avant le processeur.

Limites et fichiers temporaires

  • -j n’est pas disponible pour les entrées compressées ou au format CSV et repose sur la duplication de processus, il n’est donc pas compatible avec Windows.
  • La lecture distante de fichiers CSV n’est pas prise en charge par le mécanisme de lecture distante du projet amont.
  • L’analyse parallèle crée des fichiers temporaires nommés comme tmp_pgbadgerXXXX.bin dans le répertoire temporaire sélectionné (par défaut, le répertoire temporaire du système).
  • Ne supprimez pas ces fichiers pendant l’exécution de pgBadger. Utilisez --tempdir pour les placer sur un stockage disposant d’une capacité suffisante.
  • Commencez avec un nombre modeste de processus de travail et surveillez la charge CPU, le débit de lecture, la consommation d’espace temporaire et le temps écoulé.