PHSOFT - server

서버가 “매일 새벽만 느려져요” 같은 패턴을 보이면 cron이 원인일 가능성이 높습니다. 중요한 건 감으로 고치지 않고 측정 → 병목 → 개선 순서로 접근하는 겁니다.

지금부터는 증상 정리부터, 점검 체크리스트, 그리고 해결 단계를 순서대로 진행해볼게요.

참고로 웹은 nginx 기준으로 예시를 넣지만, 핵심은 어떤 스택에서도 동일합니다.

증상: “특정 시간에만” 느려지는 패턴부터 잡기

cron 이슈는 대체로 피크 시간이 정해져 있습니다. 아래 중 2개 이상이면 cron부터 의심하는 게 빠릅니다.

이 단계에서는 “느리다”를 숫자로 바꾸는 게 목표입니다.

아래 체크리스트를 위에서 아래로 진행하면, 원인 후보가 빠르게 줄어듭니다.

체크 중 “딱 그 시간에만 튄다”가 보이면, 이제부터는 거의 추적 게임이 아니라 데이터 기반으로 좁혀집니다.

먼저 “누가 무엇을 돌리는지”를 정리합니다.

사용자 crontab: crontab -l (서비스 계정도 포함)
시스템 cron: /etc/crontab, /etc/cron.d/, /etc/cron.daily|hourly|weekly|monthly
systemd timer 사용 여부: systemctl list-timers

실행 로그는 배포판마다 다르지만, 보통은 아래 중 하나에 있습니다.

여기서 중요한 포인트는 “실행 시각”과 “실제로 어떤 커맨드가 돌았는지”를 한 줄로라도 남기는 겁니다.

cron이 성능을 망치는 방식은 보통 3가지 중 하나입니다: CPU를 태우거나, 메모리를 잡아먹거나, 디스크 I/O를 막습니다.

새벽 배치가 압축(tar/gzip), 백업(rsync), 로그 처리, 대량 파일 스캔(find) 같은 작업이면 디스크 병목이 자주 나옵니다.

반대로 데이터 변환/이미지 처리/대량 암호화 같은 작업이면 CPU가 주범인 경우가 많습니다.

웹이 느리다고 해서 항상 nginx가 원인은 아닙니다. 하지만 nginx 로그는 “느림이 언제 시작됐는지”를 정확히 찍어주기 때문에 관제 포인트로 좋습니다.

만약 nginx는 정상인데 upstream만 느려진다면, cron이 DB나 애플리케이션 리소스를 잡아먹는 흐름을 의심할 수 있습니다.

측정으로 병목이 어느 쪽인지 잡았다면, 이제는 위험을 낮추는 순서대로 바꿉니다.

특히 같은 시간대에 여러 cron이 몰리면 “각각은 괜찮은데 합치면 폭발”이 흔합니다. 스케줄을 5~10분 단위로라도 흩어두는 것만으로 체감이 크게 좋아질 때가 많아요.

또 하나: 로그 로테이션(logrotate)이나 백업이 nginx 로그 디스크를 꽉 잡으면, 웹 응답도 같이 밀릴 수 있습니다. 디스크 병목이면 가장 먼저 의심해볼 만합니다.

cron 성능 문제는 “무슨 작업이 언제 자원을 얼마나 쓰는지”만 잡히면, 대부분은 정리 가능합니다. 측정으로 근거를 만들고, 병목을 하나로 좁힌 뒤, 안전한 순서로 개선해보세요.

다음 글로는 $request_time 로그 포맷 추가나, systemd timer로 옮길 때의 운영 팁처럼 “재발 방지” 쪽을 더 깊게 다뤄도 좋습니다.