backend_flush_after
| 버전 | 기본값 | context | 타입 |
|---|---|---|---|
| 14 | 0 | user | integer |
| 15 | 0 | user | integer |
| 16 | 0 | user | integer |
| 17 | 0 | user | integer |
| 18 | 0 | user | integer |
| 19 | 0 | user | integer |
backend 하나가 이 양보다 많은 데이터를 쓰면 OS가 해당 쓰기를 storage로 내려보내도록 강제한다. 단위 없이 값을 주면 블록(BLCKSZ, 보통 8kB) 단위로 해석하며, 허용 범위는 0부터 2MB까지다. 기본값은 0으로 강제 writeback을 하지 않는다.
이렇게 하면 kernel의 page cache에 쌓이는 dirty data 양이 제한된다. checkpoint 마지막에 fsync가 실행될 때나 OS가 큰 배치로 데이터를 되쓰는 시점에 발생하는 stall 가능성이 줄어들어, 트랜잭션 지연이 크게 개선되는 경우가 많다. 다만 workload가 shared_buffers보다는 크지만 OS의 page cache보다는 작은 상황에서는 오히려 성능이 나빠질 수 있고, 일부 플랫폼에서는 이 설정이 아무 효과가 없다.
운영 노트: 기본값 0(비활성)이 무난하다. checkpoint 시점의 I/O spike로 트랜잭션 지연이 튀는 서버라면
bgwriter_flush_after, checkpoint_flush_after와 함께 검토해 볼 만하지만, 데이터가 OS page cache 안에 대부분 들어가는 workload에서는 강제 writeback이 재쓰기 기회를 없애 손해가 될 수 있다.출처: PostgreSQL 18 문서