Быстрый COMMIT в PostgreSQL: как проверить запись WAL на диск

END (COMMIT) за 60 мкс выглядит как удачная настройка PostgreSQL. Но в опыте Postgres Professional синхронная фиксация заняла около 223 мкс. Отключённая синхронизация сократила тот же шаг до 60 мкс.

Администратору 1С нужен не рекорд TPS. Нужно понять, переживёт ли проведённый документ отключение питания, сбой ядра или аварийную перезагрузку. Один диагностический сеанс покажет, ждёт ли PostgreSQL записи WAL на накопитель.

Что PostgreSQL делает перед ответом COMMIT

PostgreSQL сначала пишет сведения об изменениях в WAL — журнал предзаписи. Страницы таблиц попадут на диск позже, но журнал уже содержит данные для восстановления.

При COMMIT сервер формирует запись о завершении транзакции. Затем процесс PostgreSQL передаёт её операционной системе через write или pwrite64.

Одного write недостаточно. Данные могли попасть только в кэш ОС, который исчезнет при потере питания.

Для принудительной записи PostgreSQL вызывает fsync или fdatasync. При синхронной фиксации ответ клиенту приходит после сброса WAL в постоянное хранилище. Этот порядок описывает документация PostgreSQL 18 в разделе Asynchronous Commit.

Для 1С граница проходит по сообщению «документ записан». Если сервер подтвердил транзакцию до сброса WAL, пользователь считает операцию завершённой, хотя данные ещё можно потерять.

Вывод: асинхронный COMMIT ограничивает риск последними операциями, а отключённый fsync ставит под угрозу весь кластер.

Почему 60 мкс требуют проверки

В опыте Postgres Professional шаг END (COMMIT) занял около 223 мкс при включённом fsync. После отключения синхронизации задержка упала примерно до 60 мкс.

В той же статье физический цикл синхронизации корпоративного NVMe оценён в 100–150 мкс. Автор получил полный синхронный COMMIT в диапазоне 150–250 мкс. Это результаты одного опыта, а не норматив для каждого сервера.

Задержка зависит от накопителя, контроллера, файловой системы и метода wal_sync_method. Поэтому нельзя браковать сервер только из-за результата ниже 150 мкс. Сначала проверьте, какой путь прошла запись.

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

Так работает групповой COMMIT: PostgreSQL сбрасывает WAL сразу для нескольких транзакций. На нагруженном тесте стоимость одной операции распределяется между клиентами.

Чтобы увидеть задержку одной транзакции, запускайте pgbench с одним подключением:

pgbench -c 1 -j 1 -T 60 имя_базы

Параметр -c 1 убирает влияние параллельных клиентов. Такой прогон не воспроизводит рабочую нагрузку 1С, зато делает путь одиночного COMMIT заметнее.

Короткий тест диска тоже может обмануть. Он успевает измерить кэш контроллера, а не массив за ним. Условия такого прогона описаны в материале о том, когда результатам синтетического теста дисков можно верить.

Сначала проверьте параметры фиксации

Получите действующие значения из того экземпляра PostgreSQL, к которому подключена база 1С:

SHOW fsync;
SHOW synchronous_commit;
SHOW wal_sync_method;
SHOW wal_writer_delay;

Проверяйте результат в рабочем сеансе. synchronous_commit можно менять для отдельной транзакции или подключения, поэтому значение в postgresql.conf не всегда описывает поведение конкретного клиента.

Параметр fsync действует на весь сервер. Документация PostgreSQL предупреждает: после системного сбоя режим fsync = off может вызвать неисправимое повреждение данных.

Качественный контроллер или серверный NVMe не отменяет этот риск. Команда могла остаться в кэше ОС, накопителя либо контроллера.

Для хозяйственных операций 1С оставляйте оба параметра включёнными:

fsync = on
synchronous_commit = on

Асинхронный режим годится только для данных, которые можно повторно загрузить или пересоздать. Проведённые документы, движения регистров и изменения справочников к таким данным не относятся.

Измерьте синхронизацию в файловой системе WAL

Утилита pg_test_fsync сравнивает методы, которыми PostgreSQL синхронизирует WAL. Она выводит среднее время операции для каждого поддерживаемого варианта wal_sync_method.

Тестовый файл должен лежать в той же файловой системе, что и каталог pg_wal. Иначе вы измерите другой накопитель, другой массив или другой слой хранения.

Пример команды:

pg_test_fsync -f /путь/к/файловой-системе/pg_wal/pg_test_fsync.out

Не размещайте тестовый файл внутри рабочего pg_wal. Выберите отдельный каталог на том же томе или точке монтирования.

По документации PostgreSQL 12 один тест по умолчанию длится пять секунд. Полный набор проверок занимает около двух минут.

pg_test_fsync не измеряет скорость всей базы 1С. Документация прямо предупреждает: различия между методами могут слабо влиять на работу PostgreSQL, если сервер упирается не в WAL.

Вывод: ни одна проверка не доказывает сохранность отдельно, но их совпадение выявляет отключённую синхронизацию.

Сопоставьте pgbench и pg_test_fsync

Сначала запишите среднее время pg_test_fsync для метода, который использует сервер. Затем проведите однопоточный прогон pgbench и найдите задержку END (COMMIT).

Не ждите равенства результатов. COMMIT включает больше действий, чем один вызов синхронизации, а фоновые процессы добавляют разброс.

Подозрение вызывает другая картина: COMMIT стабильно завершается быстрее среднего времени синхронизации на той же файловой системе. Это повод проверить параметры и системные вызовы, а не готовый диагноз.

В опыте Postgres Professional разница была явной: около 223 мкс с синхронизацией против 60 мкс без неё. На вашем сервере абсолютные значения будут другими.

Не сравнивайте результаты разных томов. Файл pg_test_fsync на системном SSD ничего не говорит о WAL, размещённом на сетевом хранилище или RAID-массиве.

Проверьте системные вызовы PostgreSQL

strace показывает обращения процесса PostgreSQL к ядру Linux. Для этой проверки нужны четыре вызова: write, pwrite64, fsync и fdatasync.

Пример фильтра для заранее найденного PID:

strace -f -e trace=write,pwrite64,fsync,fdatasync -p PID

Запустите одну короткую транзакцию из тестовой базы и остановите трассировку. В выводе должна прослеживаться запись и команда синхронизации.

Трассировку лучше проводить на отдельном стенде или в согласованное окно диагностики. strace вмешивается в работу процесса, поэтому долгий сбор на нагруженном сервере исказит задержки.

Наличие fsync или fdatasync подтверждает поведение PostgreSQL и ОС. Оно не доказывает, что контроллер либо накопитель честно сохранил данные в энергонезависимой памяти.

Такую гарантию проверяет испытание с потерей питания. Проводить его на рабочем сервере нельзя: нужен отдельный стенд и проверяемая копия базы.

Сколько операций можно потерять при asynchronous commit

Документация PostgreSQL задаёт верхнюю границу окна риска как три значения wal_writer_delay. Это не среднее время потери, а максимальная задержка фонового сброса WAL.

Возьмём пример с wal_writer_delay = 200 ms. Это допущение для расчёта, а не измерение конкретного сервера:

3 × 200 мс = 600 мс

При аварии могут исчезнуть подтверждённые транзакции за последние 600 мс. Для другого значения подставьте свой wal_writer_delay в ту же формулу.

После запуска PostgreSQL воспроизведёт WAL до последней сброшенной записи. База вернётся в согласованное состояние, но операций из окна риска в ней не будет.

Немедленная остановка PostgreSQL создаёт тот же риск, что и сбой. Документация относит immediate-mode shutdown к событиям, при которых несброшенные асинхронные транзакции теряются.

Для очереди повторяемых служебных заданий такой компромисс может подойти. Для проведения документов 1С он опасен: пользователь получил подтверждение и не станет повторять операцию.

Асинхронную фиксацию лучше назначать точечно для некритичных транзакций. Не отключайте ради неё fsync на всём сервере.

Почему fsync нельзя выключать ради TPS

При synchronous_commit = off PostgreSQL продолжает сбрасывать WAL и сохраняет структуру базы согласованной. Риск ограничен последними подтверждёнными транзакциями.

При fsync = off сервер перестаёт ждать физической записи изменений. После сбоя повреждение может затронуть произвольные страницы и весь кластер.

Тогда недостаточно повторить несколько операций. Потребуется восстановление из резервной копии, а при настроенном архиве WAL — возврат к выбранному моменту. Безопасный порядок описан в инструкции по восстановлению PostgreSQL через отдельную копию и WAL.

Если fsync уже работал в режиме off, одного изменения параметра на on мало. Документация PostgreSQL требует сначала сбросить изменённые буферы ядра в хранилище.

Для этого подходят initdb --sync-only, системная команда sync, размонтирование файловой системы или перезагрузка сервера. Выберите способ по устройству вашего контура и правилам остановки 1С.

После сброса проверьте значение параметра:

SHOW fsync;

Затем повторите pg_test_fsync, однопоточный pgbench и трассировку системных вызовов. Старые результаты уже не описывают новый режим.

Проверка перед вводом сервера 1С

Не принимайте сервер по одному показателю TPS. Подтверждённую операцию можно считать сохранённой, когда совпали три признака:

1. fsync установлен в on.
2. synchronous_commit установлен в on для хозяйственных операций 1С.
3. Однопоточный тест и трассировка показывают реальную синхронизацию WAL.

Если COMMIT заметно быстрее среднего времени pg_test_fsync, вернитесь к параметрам и системным вызовам. Само низкое время ещё не доказывает ошибку накопителя.

Если некритичным операциям нужна меньшая задержка, меняйте synchronous_commit только для них. fsync оставляйте включённым: выигрыш в TPS не стоит восстановления всего кластера.