Перейти к содержанию

Параллельная обработка

Выбор между параллельной обработкой частей одного журнала и множества журналов

pgBadger поддерживает два взаимодополняющих режима многопроцессной обработки. Выбирайте режим по структуре входных данных, а не просто по числу процессоров.

ПараметрЕдиница параллельной обработкиЛучше всего подходит дляОсновное ограничение
-j N / --jobs Nчасти одного файла журналаодин большой журнал с произвольным доступомна границах частей небольшое число запросов может быть продублировано или пропущено
-J N / --Jobs Nцелые файлы журналовмножество независимых журналовполезно только при достаточном числе файлов для постоянной загрузки рабочих процессов

Разделение одного большого файла с -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

Каждый рабочий процесс получает целый файл, поэтому в этом режиме отсутствует проблема границ частей. Он наиболее полезен при сотнях небольших файлов и достаточной мощности процессора и подсистемы ввода-вывода. Документация исходного проекта также разрешает использовать -J для независимых сжатых файлов; разделение одного файла с -j требует несжатых входных данных с произвольным доступом.

Эталонные измерения исходного проекта

В руководстве исходного проекта приведены следующие результаты для узла с 8 процессорами. Рассматривайте их как сравнение двух алгоритмов, а не как прогноз для современного оборудования.

Один файл размером 9,5 ГБ:

Параметр1 CPU2 CPU4 CPU8 CPU
-j1h41m1850m2525m3915m58
-J1h41m1854m2841m1634m45

Двести файлов по 10 МБ, всего 2 ГБ:

Параметр1 CPU2 CPU4 CPU8 CPU
-j20m159m565m204m20
-J20m159m495m002m40

Практическое правило: используйте -j для нескольких больших файлов, а -J — для множества небольших. Если входные данные и платформа позволяют, оба режима можно сочетать, но такую комбинацию следует измерить: пропускная способность хранилища может стать ограничением разбора журналов раньше, чем процессор.

Ограничения и временные файлы

  • -j недоступен для сжатого ввода или CSV и использует создание дочерних процессов, поэтому этот режим не работает в Windows.
  • Путь удалённого ввода исходного проекта не поддерживает разбор удалённых CSV.
  • При параллельном анализе в выбранном временном каталоге (по умолчанию — системном) создаются файлы с именами вида tmp_pgbadgerXXXX.bin.
  • Не удаляйте эти файлы во время работы pgBadger. С помощью --tempdir разместите их в хранилище достаточного объёма.
  • Начните с умеренного числа рабочих процессов и следите за загрузкой процессора, скоростью чтения, использованием временного пространства и затраченным временем.