並列処理

pgBadgerには相互に補完する2つのマルチプロセスモードがあります。単にCPU数だけでなく、入力の構成に応じて選択してください。

-jで大きなファイルを分割する

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

アップストリームのアルゴリズムは、各ファイルをN個のバイト範囲に分割し、範囲ごとにパーサーをフォークして一時的なバイナリ統計を書き出した後、その統計を最終レポートに統合します。

for each log file
    divide the file into N chunks
    find each chunk's start and end offsets
    fork N parsers at those offsets
    write one temporary binary statistics file per parser
wait for the workers
merge the binary files and build the report

ログレコードや複数行のステートメントはバイトオフセットと完全には一致しないため、分割境界では、ファイルごとに最大でおよそN個のクエリーが途中で切れたり、欠落したり、より一般的には二重に数えられたりする場合があります。このモードは非常に大きなファイルの集計分析に使用し、すべてのレコードを厳密に数える必要がある調査には使用しないでください。

-Jで多数のファイルを処理する

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

各ワーカーがファイル全体を担当するため、このモードでは分割境界での欠落を回避できます。数百の小さなファイルと十分なCPU・I/O能力がある場合に特に有効です。アップストリームのドキュメントでは、独立した圧縮ファイルに対しても-Jを使用できます。-jによる単一ファイルの分割には、シーク可能な非圧縮入力が必要です。

アップストリームのベンチマーク

アップストリームのマニュアルでは、8 CPUのホストで測定した次の結果が報告されています。現在のハードウェアの性能予測ではなく、2つのアルゴリズムの比較として参照してください。

9.5 GBのファイル1つ：

10 MBのファイル200個、合計2 GB：

実用上の基本は、少数の大きなファイルには-j、多数の小さなファイルには-Jです。入力とプラットフォームが対応していれば両モードを組み合わせられますが、その組み合わせでベンチマークを実施してください。ログ解析は、CPUより先にストレージのスループットが制約になる場合があります。

制限と一時ファイル

• -jは圧縮入力やCSV入力には使用できません。また、プロセスのフォークに依存するため、Windows向けのモードではありません。
• アップストリームのリモート入力機能では、リモートCSVの解析はサポートされていません。
• 並列解析では、選択した一時ディレクトリ（デフォルトではシステムの一時ディレクトリ）にtmp_pgbadgerXXXX.binのような名前の一時ファイルを作成します。
• pgBadgerの実行中はこれらのファイルを削除しないでください。--tempdirを使用して、十分な容量のあるストレージに配置します。
• 最初は控えめなワーカー数で開始し、CPU、読み取りスループット、一時領域の使用量、経過時間を監視してください。