vacuum_cost_delay
| 버전 | 기본값 | context | 타입 |
|---|---|---|---|
| 14 | zero | user | string |
| 15 | zero | user | string |
| 16 | zero | user | string |
| 17 | zero | user | string |
| 18 | 0 | user | string |
| 19 | 0 | user | string |
cost 기반 vacuum delay 체계에서, 누적 비용이 한도를 넘었을 때 프로세스가 잠들어 있을 시간을 정한다. 단위 없이 값을 주면 밀리초로 해석한다. 기본값은 0으로, 수동 VACUUM에서는 cost 기반 delay가 꺼져 있다는 뜻이다. 양수를 주면 cost 기반 vacuum이 켜진다.
이 체계의 동작은 이렇다. vacuum이 페이지를 처리할 때마다 작업 종류별 비용(vacuum_cost_page_hit, vacuum_cost_page_miss, vacuum_cost_page_dirty)이 누적되고, 누적치가 vacuum_cost_limit에 도달하면 프로세스가 vacuum_cost_delay만큼 잠들었다가 카운터를 리셋하고 재개한다. vacuum의 I/O 사용량을 일부러 늦춰서 일반 쿼리에 주는 영향을 줄이는 장치다. 참고로 autovacuum은 별도의 autovacuum_vacuum_cost_delay(기본 2ms)를 쓰므로, 이 파라미터의 기본값이 0이어도 autovacuum은 throttle이 걸린 상태로 돈다.
cost 기반 vacuum을 쓸 때 적절한 값은 대개 아주 작아서 1밀리초 미만인 경우가 많다. 밀리초 이하의 소수 값도 설정할 수 있지만 오래된 플랫폼에서는 그런 짧은 지연이 정확히 측정되지 않을 수 있다. 그런 플랫폼에서 1ms 수준 이상으로 vacuum 처리량을 조절하려면 delay가 아니라 다른 vacuum cost 파라미터를 바꿔야 한다. 어느 쪽이든 delay는 플랫폼이 일관되게 측정할 수 있는 한도 안에서 최대한 작게 유지하는 것이 좋다. 긴 delay는 도움이 되지 않는다.
vacuum_cost_limit을 조정하는 쪽이 보통 낫다. delay가 길면 vacuum이 필요 이상으로 늘어져 bloat와 wraparound 위험이 커진다.출처: PostgreSQL 18 문서