네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지
빠른 LAN 검색, 플랫폼 간 스캔 및 IP 주소 관리를 위한 10가지 핑 스윕 도구를 비교해 보세요. 스윕을 통해 무엇을 알 수 있고 무엇을 알 수 없는지 알아보세요.
메일 흐름을 방해하지 않고 Zimbra Amavis의 CPU 사용률 100% 문제를 해결하는 방법
좋은 해결책은 이런 모습이어야 한다
프로세스가 CPU 사용률 100%에 도달하거나 근접했을 때 amavisd, 단순히 해당 프로세스를 종료하는 것만이 목표는 아닙니다. 효과적인 해결책은 정상적인 메일 흐름을 복원하고, 처리 지연 시간을 줄이며, 스팸 및 바이러스 방지 기능이 계속 작동하도록 유지하고, Postfix 큐가 더 이상 증가하지 않도록 해야 합니다.
Zimbra에서 Amavisd-New는 MTA와 콘텐츠 스캐너 사이에 위치합니다. Zimbra의 최신 Daffodil 관리 가이드에서는 Amavisd-New를 Zimbra MTA, ClamAV 및 SpamAssassin 간의 인터페이스로 설명합니다. 즉, CPU 사용량 급증은 Amavis 자체, SpamAssassin 규칙 또는 메시지 내용, 바이러스 검사, 또는 모든 워커가 바쁘게 작동하는 백로그 등 다양한 원인에서 발생할 수 있습니다. 자세한 내용은 Zimbra Daffodil 관리자 가이드를 참조하십시오 .
성공적인 결과는 다음 네 가지 징후로 나타납니다. Amavis CPU 사용량이 안정적인 수준으로 떨어지고, 지연 및 활성 큐의 증가세가 멈추며, 새 메시지가 비정상적인 지연 없이 처리되고, 스팸 방지/바이러스 방지 서비스가 정상적으로 작동하는 것입니다. 필터링을 비활성화하여 CPU 사용량이 감소한 경우, 근본적인 문제는 해결되지 않은 것입니다.
1단계: Amavis가 실제로 CPU 사용량이 가장 많은 프로그램인지 확인합니다.
운영 체제 수준에서부터 문제를 해결하십시오. 메일 전송이 느리다는 이유만으로 Amavis가 원인이라고 단정짓지 마십시오. 가장 사용량이 많은 프로세스를 확인하고 하나 이상의 amavisd워커 프로세스가 지속적으로 CPU 코어를 완전히 점유하고 있는지 확인하십시오.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
캡션: amavisd가 CPU 사용량의 대부분을 차지하는 터미널 화면입니다. 이는 Zimbra 설정을 변경하기 전에 확인해야 할 첫 번째 조건입니다.
대용량 메시지나 압축 첨부 파일을 스캔하는 동안 순간적으로 CPU 사용량이 급증하는 것은 정상적인 현상입니다. 하지만 메일 지연이나 큐 깊이가 증가하면서 동일한 증상이 지속된다면 이는 지속적인 문제로 간주해야 합니다. 또한 로드 평균, 사용 가능한 메모리, 스왑 활동 및 I/O 대기 시간도 확인하십시오. CPU 사용량이 높고 스왑 또는 스토리지 경합이 심한 경우에는 Amavis만 수정하는 것보다 호스트 수준에서 더 광범위한 조사가 필요할 수 있습니다.
2단계: 재시작하기 전에 Zimbra 서비스 상태를 확인하세요.
Zimbra 계정으로 전환하여 서비스 상태를 확인하십시오. Zimbra 문서에서는 zmcontrol status서비스 활성화 여부를 확인하는 표준 방법으로 이 방법을 제시합니다.
su - zimbra
zmcontrol status
zmamavisdctl status
캡션: 문제 해결 시작 전 Amavis, 스팸 방지, 바이러스 백신 및 MTA 구성 요소가 실행 중인 Zimbra 서비스 상태를 보여줍니다.
이 단계는 "CPU 사용률 100%"와 "서비스 중단"이 서로 다른 오류 유형이기 때문에 중요합니다. Amavis가 실행 중이 아니라면 시작 오류를 조사하십시오. Amavis가 실행 중이지만 과부하 상태라면 큐 및 로그 분석을 진행하십시오.
3단계: CPU 사용량뿐 아니라 메일 큐 사용량도 측정하십시오.
큐 깊이는 높은 CPU 사용량이 메시지 전송에 영향을 미치는지 여부를 알려줍니다. Zimbra의 큐 문제 해결 자료 zmqstat에서 큐 개수를 확인하고 Postfix 큐 명령어를 사용하여 메시지 세부 정보를 확인할 수 있습니다. 몇 분 간격으로 반복적으로 검사를 실행하십시오.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
설명: 큐 통계와 지연된 메시지는 CPU 사용률만으로는 측정할 수 없는 메일 흐름 영향에 대한 더 나은 지표를 제공합니다.
개별적인 수치 하나가 아니라 전체적인 추세를 살펴보세요. 샘플링할 때마다 대기열이 증가한다는 것은 처리량이 도착률보다 낮다는 의미입니다. 반대로 변경 후 대기열이 꾸준히 감소하는 것은 변경 사항이 실제로 도움이 되었다는 가장 강력한 신호 중 하나입니다.
여러 개의 MTA를 사용하는 배포 환경에서는 문제가 발생하는 MTA 노드를 구체적으로 확인하십시오. 다른 노드의 큐에도 동일한 병목 현상이 나타난다고 가정하지 마십시오.
4단계: Zimbra 로그를 사용하여 속도가 느린 단계를 확인합니다.
Amavis 및 SpamAssassin 문제 해결 메시지는 해당 파일에 기록됩니다 /var/log/zimbra.log. CPU 사용량 급증 시간대를 중심으로 검색하여 메시지 ID, 프로세스 ID 및 스캔 지속 시간을 연관시켜 분석하십시오.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
캡션: Amavis 및 SpamAssassin 로그 라인을 통해 개별 메시지 또는 검사 단계가 비정상적으로 오래 걸리는지 확인할 수 있습니다.
유용한 패턴으로는 SpamAssassin 스캔 시간이 반복적으로 길어지는 경우, 동일한 큐 ID에 대해 반복적으로 재시도하는 경우, ClamAV 통신 오류, 압축 해제 관련 오류 또는 작업자 리소스를 반복적으로 소모하는 소수의 메시지 등이 있습니다. Zimbra의 문제 해결 문서에서는 스캔 지연으로 메일 흐름이 중단될 경우 Amavis 및 SpamAssassin 디버그 로깅을 사용할 것을 권장합니다. 자세한 내용은 Zimbra의 로깅 문제 해결 참조 문서를 확인하세요 .
5단계: 일반 로그에서 명확한 결과를 얻을 수 없는 경우 Amavis 로깅 수준을 일시적으로 높이십시오.
Zimbra는 Amavis와 SpamAssassin에 대해 별도의 로깅 제어 기능을 제공합니다. Amavis의 로깅 레벨 범위는 0에서 5까지이며, SpamAssassin은 zimbraAmavisSALogLevel0 또는 1을 사용합니다. 심층적인 디버깅이 필요한 경우가 아니라면 최대 상세도보다는 Amavis 레벨 2부터 시작하는 것이 좋습니다.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
캡션: 임시 로깅 변경으로 스캔 타이밍과 SpamAssassin 동작을 CPU 사용량 급증과 더 쉽게 연관시킬 수 있습니다.
문제 재현 또는 관찰은 유용한 데이터를 수집할 수 있을 만큼만 하십시오. 로깅 수준을 높이면 디스크 쓰기 작업이 증가하여 사용량이 많은 서버가 더 시끄러워질 수 있습니다. 조사가 완료되면 이전 값으로 되돌리십시오. Zimbra 문서에 따르면 SpamAssassin의 기본 로깅 수준은 0이며, Amavis의 로깅은 일반적으로 낮은 볼륨으로 설정되어 있습니다.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 16단계: SpamAssassin 실행 속도가 느린 경우, 규칙을 검증하고 업데이트하십시오.
로그에 SpamAssassin 문제가 지속적으로 지적되는 경우, 규칙 변경, 사용자 지정 규칙 배포 또는 규칙 업데이트 실패 이후에 문제가 발생했는지 확인하십시오. 잘못 설계된 정규 표현식과 문제가 있는 규칙은 특정 메시지 본문에서 처리 비용이 많이 발생할 수 있습니다.
Zimbra의 공식 Amavis 문제 해결 자료에는 ZCS 8.8 이상 버전에 포함된 SpamAssassin 업데이트 명령이 다음과 같이 설명되어 있습니다.
su - zimbra
/opt/zimbra/common/bin/sa-update -D
캡션: 로그 또는 시작 오류에서 규칙 데이터가 오래되었거나 손상된 것으로 나타날 경우, 번들로 제공되는 SpamAssassin 규칙을 업데이트하는 것이 적절합니다.
이 방법을 CPU 문제 해결의 만능 해결책으로 간주하지 마십시오 sa-update. 사용자 지정 규칙을 추가한 직후에 CPU 사용량 급증이 발생했다면 해당 규칙을 먼저 테스트하십시오. Zimbra는 최신 사용자 지정 SpamAssassin 규칙을 에 저장합니다 /opt/zimbra/data/spamassassin/localrules/. 관리 기간 동안 문제가 되는 사용자 지정 규칙만 제거하거나 비활성화한 다음 검사 시간과 대기열 동작을 비교하십시오.
짐브라 공식 위키에는 최신 ZCS 릴리스에 대한 자동 규칙 업데이트 및 컴파일 설정에 대한 내용도 나와 있습니다. 기존 서버에서 자동화된 동작을 활성화하기 전에 짐브라 스팸 방지 전략을 검토하십시오.
7단계: 변경 사항을 확인한 후에만 Amavis를 다시 시작하십시오.
재시작을 통해 멈춰있는 워커를 해결하고 업데이트된 규칙을 로드할 수 있지만, 재시작은 진단 후에 이루어져야 하며 교체해서는 안 됩니다. 더 넓은 MTA 스택에 문제가 있는 것으로 의심되는 경우가 아니라면 Amavis만 먼저 재시작하십시오.
su - zimbra
zmamavisdctl restart
설명: Amavis를 재시작하면 특정 규칙이나 구성 변경 후 서비스가 다시 로드되지만, 모든 Zimbra 서비스를 불필요하게 재시작할 필요는 없습니다.
CPU 사용률이 즉시 100%로 돌아간다면, 이는 원인이 여전히 존재한다는 유용한 증거입니다. 로그를 다시 확인하여 동일한 메시지, 스캐너 또는 규칙이 다시 나타나는지 확인하십시오. 서비스를 반복적으로 재시작하면 큐가 커지는 동안 증상이 일시적으로 완화될 수 있습니다.
8단계: 세 가지 독립적인 검사를 통해 복구 여부를 확인합니다.
CPU 사용량이 한 번 낮아졌다고 해서 문제가 해결되었다고 단정짓지 마십시오. 프로세스 부하, 큐 방향, 서비스 상태를 종합적으로 확인해야 합니다.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
캡션: CPU 사용량, 대기열 깊이 및 Zimbra 서비스 상태가 모두 동시에 개선될 때 복구 성능이 더 강력해집니다.
그런 다음 해당 MTA를 통해 테스트 메시지를 보내고 정상적인 지연 시간 범위 내에서 전달되는지 확인하십시오. 필터링을 통과해야 하는 메시지의 경우 헤더에서 Zimbra/Amavis 스팸 및 바이러스 검사 관련 필드를 확인하십시오. Zimbra는 이러한 검사가 활성화된 경우 X-Virus-Scanned표시 되는 헤더 정보를 문서화합니다.X-Spam-Status
다음에 무엇을 해야 할지 결정하는 방법
| 당신이 관찰하는 것 | 다음 조치로 가장 적합한 것 | 왜 |
|---|---|---|
| 하나의 메시지로 인해 반복적으로 긴 스캔 시간이 발생합니다. | 해당 메시지를 안전하게 격리하거나 검사하고, 큐 ID를 로그와 대조하십시오. | 병목 현상은 용량 문제라기보다는 콘텐츠 특성과 관련된 문제일 수 있습니다. |
| SpamAssassin의 타이밍이 중요합니다. | 사용자 지정 규칙, 규칙 업데이트 및 디버그 출력을 검토하세요. | 정규 표현식이 많이 사용되거나 손상된 규칙 세트는 점수 계산 비용을 증가시킬 수 있습니다. |
| ClamAV 오류 또는 시간 초과가 주된 문제입니다. | 바이러스 백신 상태 및 업데이트 상태를 점검합니다. | Amavis는 단순히 호출하는 스캐너의 응답을 기다리고 있는 것일 수도 있습니다. |
| CPU 사용률은 높지만 대기열은 거의 0에 가깝습니다. | 급격한 변화를 주기 전에 좀 더 오랜 기간 관찰하세요. | 처리량과 지연 시간이 양호한 수준을 유지한다면 높은 활용률은 허용될 수 있습니다. |
| 특정 문제를 해결한 후에도 대기열은 계속 늘어납니다. | 용량, 메시지 패턴 또는 지원 수준 분석으로 문제를 확대하십시오. | 서버 용량이 부족하거나, 공격을 받고 있거나, 소프트웨어 관련 결함이 발생했을 수 있습니다. |
첫 번째 대응으로 피해야 할 변경 사항
CPU 사용량을 낮추기 위해 스팸 방지 또는 바이러스 검사를 영구적으로 비활성화하지 마십시오. Zimbra는 특정 신뢰/발신 트래픽에 대한 우회 정책을 지원하지만, 이는 보안 모델을 변경하는 것이므로 일반적인 성능 최적화가 아닌 신중한 메일 정책 결정 사항이어야 합니다. Zimbra의 SpamAssassin 발신 우회 관련 문서에는 우회가 신뢰할 수 있는 내부 네트워크와 연결되어 있음을 명확히 명시하고 있습니다.
또한 Amavis 워커 수를 맹목적으로 늘리는 것은 피해야 합니다. 워커 수가 많아지면 동시 처리량은 증가하지만 메모리 사용량이 늘어나고 CPU 경합이 심해질 수 있습니다. 적절한 워커 수는 메시지 구성, 첨부 파일 크기, 스캐너 동작, 사용 가능한 코어, 메모리 및 I/O에 따라 달라집니다. 워커 풀을 늘리면 속도가 빨라진다고 가정하기보다는 큐 처리량과 지연 시간을 기준으로 변경 사항을 테스트해야 합니다.
이 문제 해결 경로의 한계
이 절차는 Amavis가 실행 중이지만 지속적으로 CPU 사용량이 높은 일반적인 경우를 위해 설계되었습니다. 제품 결함, 손상된 서버, 악성 메시지를 이용한 서비스 거부 공격 또는 외부 스캐너가 있는 다중 노드 아키텍처와 같은 특정 문제에 대해서는 버전별 Zimbra 지원 지침을 대체하지 않습니다.
Zimbra 커뮤니티의 기술 자료에는 특수하게 조작된 메시지나 SpamAssassin의 악의적인 행위로 인해 Amavis 워커가 장시간 CPU 과다 사용 상태에 빠지는 사례가 기록되어 있습니다. 정확한 문제 발생 빈도는 설치된 Zimbra 및 SpamAssassin 버전에 따라 달라지므로, 이전 버전의 패키지 업그레이드 방법을 그대로 적용하지 마십시오. 먼저 `zmbra version` 명령어를 사용하여 Zimbra 버전을 확인하고 zmcontrol -v, 지원되는 릴리스 및 패치 레벨과 비교한 후, 최신 공급업체 지침에 따라 업그레이드하십시오.
최종 확인 체크리스트
- Amavis CPU는 더 이상 일반적인 트래픽 상황에서 지속적으로 과부하 상태에 있지 않습니다.
- 지연 대기열과 활성 대기열은 반복적인 샘플링에서 안정적이거나 감소하는 추세를 보입니다.
- 새로운 테스트 메시지가 허용 가능한 시간 내에 MTA를 통과합니다.
- Amavis, 스팸 방지, 바이러스 방지 및 MTA 서비스는 계속 실행됩니다.
- 스팸 및 바이러스 검사 헤더는 해당되는 경우 여전히 포함되어 있습니다.
- 임시 디버그 로깅 기능이 정상으로 복구되었습니다.
- 모든 사용자 지정 규칙 또는 구성 변경 사항은 업그레이드 후 검토할 수 있도록 문서화됩니다.
공식 참고 자료
성능 추적을 위한 최고의 네트워크 관리 도구 6가지
SNMP 적용 범위, 매핑, 알림, 배포 모델 및 비용 대비 효과를 포함하여 성능 모니터링을 위한 6가지 네트워크 관리 도구를 비교합니다.
Windows, iOS 및 Android용 최고의 Wi-Fi 분석기
Windows, iPhone, Android용 Wi-Fi 분석 앱들을 비교해 보세요. 채널 혼잡도, 신호 범위, 히트맵, 네트워크 문제 해결 도구 등을 포함합니다.
핑 모니터: 네트워크 가용성을 위한 7가지 무료 오픈소스 도구
종합적인 네트워크 관리 도구부터 특정 지연 시간 측정에 특화된 도구까지, 7가지 무료 오픈 소스 핑 모니터링 도구를 비교하고 가용성, 패킷 손실률, 기록 관리에 적합한 도구를 선택하세요.
네트워킹에서의 QoS: 서비스 품질(QoS)이란 무엇이며 어떻게 작동하는가
네트워킹에서 QoS가 무엇을 의미하는지, DSCP 마킹과 트래픽 큐가 음성, 비디오 및 비즈니스 애플리케이션의 우선순위를 어떻게 지정하는지, 그리고 QoS로 해결할 수 없는 문제는 무엇인지 알아보세요.
Nmap을 사용하여 트레이서루트를 실행하고 네트워크 경로를 읽는 방법
Nmap의 --traceroute 옵션을 사용하여 홉을 인증된 호스트로 매핑하고, 홉 및 RTT 출력을 이해하고, 과도한 스캔 없이 누락된 응답 문제를 해결할 수 있습니다.
안전한 파일 전송을 위한 최고의 SFTP 서버 소프트웨어
Windows 및 Linux용 안정적인 SFTP 서버 소프트웨어(OpenSSH, Bitvise, SolarWinds, SFTPGo 등)를 비교해 보세요. 보안 및 파일 전송 요구 사항에 맞는 최적의 솔루션을 찾아보세요.
네트워크 팀을 위한 최고의 IP 주소 관리 도구 7가지
서브넷 검색, DNS 및 DHCP 조정, 네트워크 인벤토리, 오픈 소스 IPAM을 위한 7가지 IP 주소 관리 도구를 비교합니다.
네트워크 모니터링 모범 사례: 추적 대상 및 사용 도구
SolarWinds NPM, PRTG 및 OpManager를 비교하여 명확한 장치 범위, 유용한 성능 지표, 실행 가능한 알림을 통해 실용적인 네트워크 모니터링 시스템을 구축하십시오.
기기 및 IP 주소 검색을 위한 최고의 네트워크 스캐너 도구 10가지
빠른 장치 검색, 플랫폼 간 IP 스캔 및 엔터프라이즈 IPAM을 위한 네트워크 스캐너 도구를 비교하고, 각 옵션을 네트워크에 맞게 선택하는 방법에 대한 지침을 제공합니다.