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

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

---

Индекс LLMS: [llms.txt](/ru/llms.txt)

---

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

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

## Разделение одного большого файла с `-j` {#single-file-jobs}

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

Алгоритм исходного проекта делит каждый файл на `N` диапазонов байтов, создаёт по одному процессу синтаксического анализа на диапазон, записывает временную двоичную статистику, а затем объединяет её в итоговый отчёт.

```text
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` {#multiple-file-jobs}

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

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

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

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

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

| Параметр | 1 CPU | 2 CPU | 4 CPU | 8 CPU |
|---|---:|---:|---:|---:|
| `-j` | 1h41m18 | 50m25 | 25m39 | 15m58 |
| `-J` | 1h41m18 | 54m28 | 41m16 | 34m45 |

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

| Параметр | 1 CPU | 2 CPU | 4 CPU | 8 CPU |
|---|---:|---:|---:|---:|
| `-j` | 20m15 | 9m56 | 5m20 | 4m20 |
| `-J` | 20m15 | 9m49 | 5m00 | 2m40 |

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

## Ограничения и временные файлы {#limits-and-temporary-files}

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

---

Обратные ссылки:

- [pgBadger](/ru/docs/pgbadger/)