ClamAV 또는 FreshClam을 사용하여 Zimbra의 높은 CPU 사용량 문제를 해결하세요.

Zimbra 서버 속도가 갑자기 느려지면 관리자는 종종 서버 상태 표시 clamd줄 freshclam상단에 top바이러스 백신 서비스가 멈춰 있다고 생각합니다. 실제로 그럴 수도 있지만, 두 프로세스는 서로 다른 작업을 수행합니다. 하나는 freshclam시그니처 업데이트를 다운로드하고 검증하는 것이고, clamd다른 하나는 파일과 메시지를 검사하는 것입니다. 메일 큐가 과부하되거나, 데이터베이스를 새로 고치거나, 업데이트 루프에 실패하거나, 또는 두 번째 바이러스 백신 데몬이 실행되는 경우 모두 "ClamAV가 CPU를 너무 많이 사용하고 있습니다"라는 오류 메시지가 나타날 수 있습니다. 서버를 재시작하거나 바이러스 백신 설정을 변경하기 전에 어떤 프로세스가 CPU를 과도하게 사용하고 있는지 파악하는 것이 중요합니다.

이 가이드는 위험도가 낮은 점검부터 서비스 복구까지 단계별로 안내합니다. 아래 명령어와 경로는 일반적인 Zimbra 설치 환경을 기준으로 작성되었으며, ClamAV가 포함된 정확한 경로와 지원되는 복구 단계는 Zimbra Collaboration 버전에 따라 다를 수 있습니다. 변경하기 전에 설치된 버전을 확인하십시오.

1. 어떤 ClamAV 프로세스가 CPU를 많이 사용하고 있는지 확인하십시오.

먼저 프로세스 이름, CPU 사용량, 경과 시간 및 명령 경로를 기록하십시오. 루트 권한 또는 시스템 프로세스를 검사할 수 있는 권한이 있는 계정으로 이 명령을 실행하십시오.

ps -eo pid,pcpu,pmem,etime,args | grep -E 'clamd|freshclam'

그런 다음 첫 번째 명령에서 얻은 숫자로 top -p PID대체하여 의심스러운 프로세스를 최소한 짧은 시간 동안 관찰하십시오 . 지속적인 문제를 진단하려면 한 번의 측정만으로는 충분하지 않습니다. 는 스냅샷을 보고하는 반면, 는 스캔이나 업데이트가 완료된 후 CPU 사용량이 높은 상태로 유지되는지 또는 감소하는지 확인하는 데 도움이 됩니다. 또한 경로가 일반적으로 아래에 있는 Zimbra에 속하는지 아니면 별도의 운영 체제 패키지에 속하는지 확인하십시오.PIDpstop/opt/zimbra

freshclam업데이트가 성공적으로 완료된 후 일시적으로 사용량이 급증했다가 종료되거나 유휴 상태로 돌아가는 경우 는 지속적으로 사용량이 많은 프로세스와는 다릅니다. 만약 clamd특정 프로세스가 지속적으로 사용량이 많다면, 메시지 스캔이나 데이터베이스 로딩이 원인일 가능성이 높습니다. 단 하나의 샘플에서 사용량이 높게 나왔다고 해서 해당 프로세스를 종료하지 마십시오. 먼저 로그를 확인하고 메일이 계속 전송되는지 확인하십시오.

2. 설정을 변경하기 전에 바이러스 백신 로그를 읽어보세요.

Zimbra의 로그 참조 목록에는 안티바이러스 로그가 로그 디렉터리에 있습니다. 대부분의 설치 환경에서는 다음 명령을 사용하여 최근 항목을 확인할 수 있습니다.

tail -n 80 /opt/zimbra/log/clamd.log
tail -n 80 /opt/zimbra/log/freshclam.log

CPU 사용량 급증과 함께 타임스탬프를 확인하세요. clamd.log반복적인 스캔 요청이나 데이터베이스 로드 메시지는 CPU 사용량 증가가 메일 활동이나 서명 재로드와 관련이 있음을 나타낼 수 있습니다. freshclam.log업데이트가 완료된 후 일정 기간 동안 사용량이 감소하는 것은 일반적인 업데이트 작업임을 시사합니다. 반복적인 연결 실패, 재시도, 체크섬 오류 또는 업데이트가 완료되지 않는 경우에는 더 자세한 조사가 필요합니다. 수신 메시지 또는 첨부 파일 트래픽이 급증하면 스캔 횟수가 증가할 수 있으므로, 같은 시간대에 Zimbra 메일 로그도 확인하세요.

Zimbra의 로그 파일 참조를 사용하여 해당 릴리스의 로그 위치를 확인하십시오. ClamAV의 FreshClam 문제 해결 가이드에서는 DNS, 다운로드 및 속도 제한 문제를 포함한 일반적인 업데이트 오류를 ​​설명합니다. 엔진이 ClamAV의 최신 업스트림 릴리스보다 오래되었다는 경고만으로는 데이터베이스가 손상되었음을 입증할 수 없습니다. Zimbra는 ZCS 릴리스에 테스트를 거친 엔진을 포함하고 있습니다.

3. 중복된 업데이트 프로그램, 디스크 공간 부족 또는 작업 부하 급증 여부를 확인하십시오.

설정을 조정하기 전에 서비스 사용량을 증가시키는 일반적인 원인을 먼저 제거하십시오.

• 중복 프로세스:clamd 프로세스가 두 개 이상 있는지 확인하십시오 freshclam. 별도로 설치된 OS 수준의 ClamAV 서비스 또는 사용자 지정 cron 작업이 Zimbra 관리 서비스와 함께 두 번째 복사본을 시작할 수 있습니다. 어떤 제품이 해당 서비스를 소유하고 있는지, 그리고 어떤 프로세스가 해당 서비스를 시작하는지 확인하기 전까지는 서비스를 비활성화하지 마십시오.
• 디스크 사용량: `dpip install`df -h /opt/zimbra 및 `dpip install` 명령어를 사용 하여 사용 가능한 공간과 inode를 확인하십시오 df -i /opt/zimbra. 파일 시스템이 가득 차면 임시 업데이트 또는 로그 쓰기가 중단되고 재시도가 발생할 수 있습니다. 공간을 확보하기 위해 서명 파일을 수동으로 삭제하지 마십시오.
• 메일 처리량: CPU 사용량 급증을 수신 메시지량, 첨부 파일 크기, 대기 중인 메일, 최근 대량 메일 전송량과 비교해 보세요. 스캔 작업이 집중적으로 발생하면 clamd서비스가 정상 상태일 때도 사용량이 급증할 수 있습니다.
• 업데이트 연결 상태 확인: 업데이트가 계속 실패하는 경우 freshclam호스트의 DNS 확인, 시간, 아웃바운드 연결 및 필요한 프록시 설정을 확인하십시오. 수동으로 업데이트 작업을 반복적으로 시작하는 대신 근본적인 네트워크 또는 프록시 문제를 해결하십시오.

ClamAV는 구성 설명서 에서 FreshClam의 구성이 업데이트 동작 및 로깅을 제어하는 ​​방법을 설명합니다 . Zimbra 또한 바이러스 정의 업데이트 빈도 속성을 설명하지만, 해당 값과 구성은 사용자의 ZCS 버전에 따라 확인해야 합니다. CPU 사용량을 줄이기 위해 업데이트 빈도를 낮추지 마십시오. 오래된 시그니처는 보안을 약화시키고, 잘못된 DNS 또는 프록시 경로는 업데이트 일정과 관계없이 계속해서 오류를 발생시킵니다.

4. 증거에 부합하면서 가장 파괴적이지 않은 해결책을 적용하십시오.

메일 폭주 중에 clamd가 바쁜 경우

현재 작업이 완료될 때까지 CPU 사용률과 메일 전송량을 모니터링하십시오. 동일한 패턴이 반복되면 메시지 크기, 압축 첨부 파일, 수신량과 연관시켜 서버 용량과 조직의 첨부 파일 검사 정책을 검토하십시오. 보안 영향을 평가하고 설치된 Zimbra 버전에서 지원하는 제어 기능을 확인하지 않고 문서화되지 않은 ClamAV 제한을 추가하거나 특정 파일 형식을 제외하지 마십시오.

freshclam이 반복적으로 실패하는 경우

로그에 표시된 DNS, 프록시, 방화벽, 시간 설정 또는 아웃바운드 네트워크 액세스 문제를 해결하십시오. Zimbra에서 지정한 업데이트 프로그램만 실행 중인지 확인하십시오. 빈번한 수동 실행을 예약하거나 임시 스크립트를 사용하여 서명 데이터베이스를 다운로드하지 마십시오. ClamAV는 FreshClam 또는 cvdupdate를 지원되는 업데이트 방법으로 식별하며, Zimbra 서버에서는 Zimbra에서 제공하는 통합 패키지가 가장 신뢰할 수 있는 업데이트 소스여야 합니다.

데이터베이스가 손상된 것처럼 보이거나 clamd가 시작되지 않는 경우

잘못된 데이터베이스, 체크섬 오류 또는 데이터베이스 로드 실패와 같은 오류가 발생한 경우 버전별 복구가 필요합니다. Zimbra의 ClamAV 정의 재설정 절차는 FreshClam 바이너리 경로를 포함하여 ZCS 세대별로 다른 지침을 제공합니다. 데이터베이스 파일을 이동하거나 재구축하기 전에 사용 중인 정확한 버전의 전체 절차를 읽어보세요. 복구가 확인될 때까지 기존 데이터베이스의 복사본을 보관하고, 이전 릴리스 가이드의 명령을 그대로 적용하지 마십시오.

성능 개선을 위한 최우선 해결책으로 Zimbra의 ClamAV 바이너리를 독립 실행형 업스트림 빌드로 교체하지 마십시오. Zimbra 문서에서는 정기 업데이트 주기 외의 엔진 변경은 지원되지 않을 수 있다고 경고합니다. 번들로 제공되는 엔진 자체를 업데이트해야 하는 경우 적절한 ZCS 패치 또는 업그레이드 경로를 사용하십시오.

원인을 확인한 후에만 바이러스 백신 서비스를 재시작하십시오.

근본적인 문제를 해결한 후에도 서비스가 계속 중단되는 경우, 안티바이러스 프로그램을 재시작하여 오래된 프로세스를 정리하거나 복구된 데이터베이스를 다시 로드할 수 있습니다. 스캔 작업을 잠시 중단해도 괜찮은 시간에 재시작 일정을 잡고, 사용 중인 ZCS 버전에 맞는 명령 시퀀스를 따르십시오. Zimbra 절차 문서에서 해당 문서를 참조 zmantivirusctl stop하고 zmantivirusctl start, 다음 사용자 권한으로 실행하십시오 zimbra.

su - zimbra
zmantivirusctl stop
zmantivirusctl start
zmcontrol status

유지 관리 플랜에 포함되어 있지 않은 경우 ClamAV 관련 문제에 대해 전체 재시작을 시도하지 마십시오 zmcontrol stop. 바이러스 백신 서비스가 다시 실행되지 않으면 관련 로그를 보존하고 재시작을 반복하는 대신 Zimbra의 릴리스별 문제 해결 또는 지원 채널을 이용하십시오.

5. CPU 사용량과 메일 스캔 속도가 정상으로 돌아왔는지 확인하십시오.

수정 또는 재시작 후에는 프로세스 점검을 반복하고, 순간적인 값 하나에 의존하지 말고 CPU 사용량 추이를 관찰하십시오. 프로세스가 정상적으로 작동하고 clamd, freshclam반복적인 재시도에 갇히지 않으며, zmcontrol status바이러스 백신이 실행 중임을 보고하는지 확인하십시오. 데이터베이스 로딩 성공 여부와 반복적인 업데이트 또는 검사 오류가 없는지 확인하기 위해 새 로그 항목을 검토하십시오. 마지막으로, 정상적인 테스트 메시지가 조직의 메일 보안 정책에 따라 전달되고 처리되는지 확인하십시오.

정상적인 복구에는 세 가지 가시적인 징후가 있습니다. 첫째, 해당 프로세스가 작업 완료 후 지속적인 CPU 사용량을 더 이상 차지하지 않습니다. 둘째, 로그에 동일한 오류가 반복해서 기록되지 않습니다. 셋째, Zimbra의 메일 흐름과 바이러스 백신 서비스 상태가 정상으로 유지됩니다. CPU 사용량이 계속 높은 경우, 타임스탬프가 포함된 프로세스 스냅샷, 해당 메일 로그 항목, 디스크 공간 결과 및 ZCS 버전을 수집하십시오 clamd.log. freshclam.log이러한 증거는 실제 스캐너 결함과 메일량 폭증 또는 업데이트 경로 오류로 인한 문제를 구분하는 데 도움이 되며, 악성코드 검사 기능을 추측에 의존하여 약화시키지 않습니다.

버전 참고: 본 지침은 2026년 10월 6일에 검토되었습니다. Zimbra 기술 센터에는 최신 참조 자료와 이전 릴리스별 문제 해결 페이지가 모두 포함되어 있습니다. 설치된 ZCS 릴리스의 설명서를 참조하여 명령 및 경로를 확인하십시오.