При синхронной фиксации PostgreSQL ждет сохранения WAL на энергонезависимом носителе. Просто передать данные в кэш ОС недостаточно: при потере питания они пропадут.
Если убрать ожидание записи, задержка COMMIT сократится, а число транзакций в секунду вырастет. Но вместе со скоростью изменятся гарантии сохранности.
Здесь важно различать два параметра:
1️⃣
fsync = off отключает принудительную синхронизацию записи. Сбой ОС или оборудования грозит потерей данных и повреждением базы.2️⃣
synchronous_commit = off разрешает отвечать клиенту до сохранения WAL. Последние транзакции могут потеряться, но этот режим сам по себе не нарушает согласованность базы.🔎 Как проверить результат бенчмарка:
✅ Измерьте задержку COMMIT с одним клиентом. Так проще увидеть вклад ожидания записи.
✅ Проверьте синхронизацию WAL. Сопоставьте настройки, системные вызовы и активность хранилища. Одна метрика еще ничего не доказывает.
✅ Проведите аварийный тест на отдельном стенде. После жесткой перезагрузки проверьте сохранность подтвержденных изменений и целостность базы.
Низкая задержка сама по себе не доказывает проблему. Но при выборе СУБД к цифрам производительности стоит добавить проверку: что останется от подтвержденных транзакций после аварии?
🔗 Читайте на Хабре, как проверить, переживут ли данные аварийный сбой.
🔔 Читайте нас в MAX