systemd RandomizedDelaySec 기준 정리

systemd RandomizedDelaySec 기준 정리

RandomizedDelaySec=는 systemd timer가 정해진 시각에 정확히 동시에 몰리는 일을 줄이기 위한 옵션이다. 2026년 7월 11일 확인 기준 systemd 261.1 공식 문서는 이 값이 0부터 지정한 시간 사이의 지연을 각 실행마다 추가한다고 설명한다.

실무에서 중요한 질문은 세 가지다. 서버 한 대 안에서 CPU wake-up을 줄이고 싶은지, 여러 장비가 같은 시각에 원격 서비스를 두드리지 않게 하고 싶은지, 재부팅 이후에도 같은 주기를 유지해야 하는지다. 이 글은 AccuracySec=, FixedRandomDelay=, RandomizedOffsetSec=, Persistent=를 함께 놓고 선택 기준을 정리한다.

RandomizedDelaySec=는 무엇을 바꿀까?

기본 OnCalendar=weekly 같은 timer는 모든 장비가 같은 기준 시각을 공유하기 쉽다. 이때 RandomizedDelaySec=를 주면 timer마다 0에서 지정값 사이의 지연이 추가되어 동시에 실행될 가능성이 줄어든다.

공식 문서 기준 기본값은 0이다. 즉 별도 설정이 없으면 분산 실행은 일어나지 않는다. 주기적 백업, 캐시 갱신, 메타데이터 동기화처럼 같은 시각에 몰리면 원격 API나 스토리지에 부하가 생기는 작업에서 특히 의미가 있다.

AccuracySec=와는 왜 다를까?

이 두 옵션은 이름이 비슷해 보여도 목적이 반대다. AccuracySec=는 가까운 timer들을 묶어서 CPU wake-up을 줄이는 절전 성격의 옵션이고, RandomizedDelaySec=는 실행 시점을 넓게 펼쳐서 동시에 몰리지 않게 하는 옵션이다.

systemd 261.1 문서는 AccuracySec= 기본값을 1분, RandomizedDelaySec= 기본값을 0으로 설명한다. 따라서 분산 효과를 강하게 원하면 RandomizedDelaySec=만 키우는 것으로 충분하지 않을 수 있다. 문서가 직접 권하는 패턴은 분산 범위를 명확히 확보하려면 AccuracySec=1us로 두고 RandomizedDelaySec=에 원하는 범위를 주는 방식이다.

매번 다른 지연이 문제라면 FixedRandomDelay=

기본 RandomizedDelaySec=는 각 반복마다 지연값을 다시 뽑는다. 그래서 어떤 주에는 3분 늦고, 다음 주에는 47분 늦는 식으로 매번 흔들릴 수 있다.

FixedRandomDelay=yes를 켜면 같은 timer 유닛의 지연값이 안정적으로 유지된다. 공식 문서는 이 값이 machine ID, 사용자 식별자, timer 유닛 이름을 바탕으로 결정되며 매니저 재시작 이후에도 유지된다고 설명한다. 같은 장비 안에서 각 timer를 서로 다른 고정 시각대로 분산하고 싶을 때 맞다.

재부팅이 잦다면 RandomizedOffsetSec=를 같이 봐야 한다

RandomizedDelaySec=는 다음 실행 시점이나 매니저 시작 시점을 기준으로 지연이 더해진다. 공식 문서의 예시처럼 OnCalendar=weekly에 RandomizedDelaySec=5 days를 주고 장비가 4일마다 재부팅된다면, 지연이 끝나기 전에 다시 시작되어 timer가 계속 실행되지 않을 수 있다.

이런 상황에서 systemd 261.1은 RandomizedOffsetSec=를 별도로 제공한다. 이 값은 OnCalendar= timer에서만 동작하며, 재부팅과 무관하게 주기 자체를 유지한 채 안정적인 오프셋을 더한다. 여러 노트북이나 엣지 장비가 주간 작업을 서로 다른 요일에 나눠 실행해야 한다면 이 쪽이 더 맞다.

Persistent=는 누락된 실행을 어떻게 다룰까?

Persistent=yes는 장비가 꺼져 있던 동안 놓친 OnCalendar= 실행이 있었다면 timer가 다시 활성화될 때 즉시 한 번 따라잡도록 돕는다. 공식 문서는 마지막 트리거 시각을 디스크에 저장하고, 비활성 기간 중 한 번 이상 실행됐어야 하면 서비스 유닛을 즉시 트리거한다고 설명한다.

다만 이 catch-up 실행도 RandomizedDelaySec=의 영향을 받는다. 즉 "전원이 켜지자마자 반드시 즉시 실행"을 기대한다면 랜덤 지연이 추가될 수 있다는 점을 같이 봐야 한다.

무난한 조합은 무엇일까?

상황	무난한 설정	이유
한 서버 안에서 wake-up 절전이 우선	AccuracySec 기본값 유지	가까운 timer를 묶어 불필요한 깨우기를 줄일 수 있음
같은 시각에 몰리는 실행만 분산	RandomizedDelaySec 설정	로컬 또는 원격 자원 부하를 넓은 구간으로 분산 가능
장비별 고정된 지연을 유지	RandomizedDelaySec + FixedRandomDelay=yes	매 반복마다 흔들리지 않고 안정적인 분산 가능
재부팅이 잦은 fleet의 주간 작업	OnCalendar + RandomizedOffsetSec	재시작 이후에도 주기와 오프셋을 유지하기 쉬움
전원 꺼짐 동안 놓친 실행도 보완	Persistent=yes	비활성 기간 중 놓친 일정이 있으면 재활성화 시 catch-up 가능

예시로 보면 더 분명하다

[Unit]
Description=Weekly backup

[Timer]
OnCalendar=weekly
AccuracySec=1us
RandomizedOffsetSec=5d
Persistent=yes

[Install]
WantedBy=timers.target

이 예시는 주간 백업을 모든 장비가 월요일 0시에 동시에 시작하지 않도록 분산하려는 경우에 가깝다. systemd.time 문서는 weekly가 Mon *-*-* 00:00:00으로 정규화된다고 설명한다. 여기서 RandomizedOffsetSec=5d를 주면 각 장비가 주기 안에서 다른 시각대를 선택할 수 있다.

반대로 한 서버 안의 여러 timer가 매시 정각에 몰리는 것만 피하고 싶다면 RandomizedDelaySec=15m와 FixedRandomDelay=yes처럼 더 단순한 조합이 실무적으로 충분한 경우가 많다.

FAQ

Q. RandomizedDelaySec=만 넣으면 항상 분산이 크게 생길까?

항상 그렇지는 않다. 공식 문서 기준 AccuracySec=가 나중 단계에서 추가 coalescing을 할 수 있다. 분산 구간을 최대한 유지하려면 문서가 제시한 것처럼 AccuracySec=1us 조합을 검토해야 한다.

Q. Persistent=yes는 모든 timer에서 의미가 있을까?

아니다. 공식 문서는 이 옵션이 OnCalendar=가 있는 timer에서만 효과가 있다고 설명한다. 단순한 OnBootSec=나 OnUnitActiveSec= 중심 timer와는 같은 방식으로 이해하면 안 된다.

Q. 일정 표현이 맞는지 어떻게 확인할까?

systemd-analyze calendar는 달력 표현을 정규화하고 다음 실행 시각을 계산하는 데 쓰인다. 예를 들어 systemd-analyze calendar weekly로 실제 해석 결과를 확인할 수 있다.

정리

RandomizedDelaySec=의 핵심은 "정해진 작업을 늦춰서 분산한다"는 점이고, AccuracySec=의 핵심은 "가까운 작업을 묶어 효율을 높인다"는 점이다. 둘은 비슷해 보여도 목표가 다르다.

대부분의 서버 한 대에서는 AccuracySec 기본값만으로도 충분할 수 있다. 하지만 같은 시각의 몰림을 피해야 하는 timer라면 RandomizedDelaySec를, 재부팅이 잦은 주기 작업이라면 RandomizedOffsetSec와 Persistent까지 함께 보는 편이 공식 문서 기준에 더 맞다.

참고 자료

• systemd 261.1 공식 문서: systemd.timer
• systemd 261.1 공식 문서: systemd.time
• systemd 261.1 공식 문서: systemd-analyze