SpamAssassin (스팸) 메모리 사용을 최소화하는 방법

Debian에서 SpamAssassin (Pyzor, AWL 및 Bayes가 비활성화되고 sa 컴파일이 활성화 된 기본 구성)을 사용하고 있으며 각 spamd 자식 프로세스는 32에서 약 100 ~ 150MB의 메모리 (약 50MB의 실제 메모리)를 소비합니다. 64 비트 서버에서이 값을 약 2 배 (논리적으로 충분)로 늘립니다. 일반적으로 두 개의 하위 프로세스가 있지만 사용량이 많은 시간에는 최대 5 개의 실행이 가능합니다.

200 ~ 600MB가이 작업을위한 많은 메모리라는 ISTM. 필터링 구조의 일부로 SA를 계속 사용하고 싶지만 너무 많은 메모리를 정당화하는 것이 어려워지고 있습니다.

각 하위 프로세스에서 사용하는 메모리 양을 줄일 수있는 방법이 있습니까? (또는 대안으로 최대 하위 항목을 2와 같이 설정할 수 있도록 단일 하위 프로세스를 너무 빨리 만드십시오.) 정확성을 떨어 뜨리거나 초래할 수있는 옵션을 포함하여 모든 옵션을 기꺼이 고려하겠습니다.

SA 위키의 "메모리 부족 문제"페이지를 이미 읽었습니다 . 아무 소용이 없습니다. 5MB보다 큰 메시지는 SA로 스캔되지 않습니다.

리눅스가 메모리 사용량을보고하는 방식을 오해하고 있다고 생각합니다. 프로세스가 분기되면 원래 프로세스와 많은 리소스를 공유하는 두 번째 프로세스가 발생합니다. 여기에는 메모리가 포함됩니다. 그러나 Linux는이를 위해 COW (Copy On Write)라는 기술을 사용합니다. 즉, 분기 된 각 하위 프로세스는 원래 프로세스와 동일한 데이터를 메모리에서 볼 수 있지만 해당 데이터가 변경 될 때마다 (자식 또는 부모에 의해) 변경 사항이 복사 된 다음 새 위치를 가리 킵니다.

프로세스 중 하나가 해당 데이터를 변경할 때까지 동일한 사본을 공유합니다. 결과적으로 100MB의 RAM을 사용하고 10 번 포크하는 프로세스를 가질 수 있습니다. 분기 된 각 프로세스에는 100MB의 사용중인 RAM이 표시되지만 상자에서 전체 메모리 사용량을 살펴보면 130MB의 사용중인 RAM (프로세스간에 100MB 공유 및 몇 MB의 오버 헤드) 만 표시 될 수 있습니다. 나머지 시스템에는 추가로 12MB 또는 2MB가 추가됩니다.

마지막 예제로 지금 30 개의 아파치 프로세스가 실행중인 상자가 있습니다. 각 프로세스는 22MB의 RAM 사용량을 보여줍니다. 그러나 free -m 을 실행 하여 전체 RAM 사용량을 표시하면 다음과 같은 결과가 나타납니다.

topher@crucible:/tmp$ free -m
             total       used       free     shared    buffers     cached
Mem:           349        310         39          0         24         73
-/+ buffers/cache:        212        136
Swap:          511         51        460

보다시피,이 박스에는 각각 18MB의 "실제"RAM을 사용하는 30 개의 프로세스를 실행하기에 충분한 RAM이 없습니다. 문자 그대로 RAM이 부족하거나 앱이 크게 바뀌지 않는 한 걱정하지 않아도됩니다.

업데이트 : 또한 Linux 메모리 사용에 대한 또 다른 질문에 대한 답변으로 jldugger 가 언급 한 smem 이라는이 도구를 확인 하십시오 .

sa-compile 을 사용하면 많은 규칙의 일치 속도를 향상시킬 수 있습니다.

여기 내가 한 일이 있습니다.

많은 메시지가 거의 동시에 전달되는 설정이 있습니다. 일련의 실험을 위해 임시 스풀에 복사 된 다음 5 분마다 크론 작업에 의해 전달되는 메시지에 대해 SA를 실행합니다.

spamd "max-children 매개 변수를 늘려야 할 것입니다."

이제 전달이 Procmail 잠금 파일에 의해 통제되는 다른 체제를 구현했습니다. 간단하기 때문에 프로세스 ID의 마지막 숫자를 사용하고 10 명의 자녀와 함께 실행합니다. 나는 이것이 최적인지 전혀 확신하지 못하지만, 때때로 경험해야 할 미친 짐 봉우리를 피하는 데 도움이되었습니다.

LINEBUF=10240

# Grab last digit of PID for lockfile
PID=$$
:0
* PID ?? ()\/[0-9]$
{ D=$MATCH }
:0
* > 512000
{ SA="(too large)" }
:0Ew:/tmp/20spamc.$D
SA=| spamc -p 38783 -l -y

또한 spamd여러 ulimit제한 사항으로 시작합니다 . 제한을 제거한 것을 제외하고 http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses 에서 숫자를 가져 왔습니다 ulimit -u. (어떻게 진행되고 있는지 확실하지 않습니다. 어떤 경우에는 32가 너무 작습니다. 500과 같은 spamd것으로 잠시 동안 계속 달릴 수는 있지만 결국 한계에 도달합니다.)

ulimit -v 204800
ulimit -m 204800
ulimit -n 256
#ulimit -u 32

perl -T -I lib -w spamd --min-children 2 --max-children 10 --max-spare 5 etc etc

로드가 너무 길면 배달 실패로 이어질 것 같지만 지금까지는로드를 관리 가능한 수준으로 낮추는 것 같습니다. 그리고 실패한 배달은 여전히 ​​스왑이 부족한 머신보다 훨씬 낫습니다.

로드 평균이 높으면 시스템에 RAM이 부족하고 (가상 메모리에서 많은 CPU 스왑 프로세스를 앞뒤로 사용하는) 간접적 인 증상이므로 SpamAssassin을 통해 메일을 전달하지 않도록 메일 서버를 구성 할 수 있습니다. 로드 평균이 너무 높습니다.

실행중인 MTA에 대해서는 언급하지 않지만 exim4의 액세스 제어 목록에서 SA를 호출하는 경우이 메시지 하단의 제안 이 효과적입니다.

또한 리소스를 덜 사용하는 다른 스팸 필터링 방법을 앞에 두어 SA에 대한로드를 줄이고 메모리 사용량을 줄일 수 있습니다 (즉, SA에 도달하기 전에 일부 스팸을 처리하고 거부 함). 예를 들어 그레이 리스팅 및 발신자 확인 콜 아웃은 상대적으로 적은 RAM을 사용합니다.

우리는 몇 달 전에 비슷한 상황에 처해있었습니다. SpamAssassin과 ClamAV는 호스팅 된 서버에서 많은 메모리를 사용하고있었습니다. 우리는 서버에 더 많은 메모리를 추가 할 수있는 옵션이 있었지만 Postini로 전환하는 것이 비용과 시간 효율성이 더 높았습니다. YMMV.