Cách giảm thiểu sử dụng bộ nhớ SpamAssassin (spamd)

Tôi đang sử dụng SpamAssassin trên Debian (cấu hình mặc định với Pykey, AWL và Bayes bị vô hiệu hóa và bật trình biên dịch) và mỗi quy trình con spamd tiêu thụ khoảng 100 đến 150 MB bộ nhớ (khoảng 50 MB bộ nhớ thực) trên 32 máy chủ bit và khoảng gấp đôi số này (đủ logic) trên máy chủ 64 bit. Nhìn chung có hai quá trình con, nhưng vào thời điểm bận rộn có thể có năm (tối đa) đang chạy.

ISTM rằng 200 đến 600 MB là rất nhiều bộ nhớ cho nhiệm vụ này. Tôi muốn tiếp tục sử dụng SA như một phần trong cấu trúc lọc của mình, nhưng việc chứng minh bộ nhớ quá nhiều trở nên khó khăn.

Có cách nào để giảm dung lượng bộ nhớ mà mỗi tiến trình con sử dụng không? (Hoặc cách khác, tạo một tiến trình con duy nhất nhanh đến mức tôi có thể đặt số lượng con tối đa thành 2?). Tôi sẵn sàng xem xét bất kỳ tùy chọn nào, kể cả những lựa chọn sẽ hoặc có thể làm giảm độ chính xác.

Tôi đã đọc trang "Mất trí nhớ" trên wiki SA ; không có gì có ích Tin nhắn lớn hơn 5 MB không được quét bằng SA.

Tôi nghĩ bạn đang hiểu sai về cách Linux báo cáo việc sử dụng bộ nhớ. Khi một quy trình rèn, nó dẫn đến một quy trình thứ hai chia sẻ nhiều tài nguyên với quy trình ban đầu. Bao gồm trong đó là bộ nhớ. Tuy nhiên, Linux sử dụng một kỹ thuật được gọi là Copy On Write (COW) cho việc này. Điều đó có nghĩa là mỗi tiến trình con rẽ nhánh sẽ thấy cùng một dữ liệu trong bộ nhớ như tiến trình ban đầu, nhưng bất cứ khi nào dữ liệu đó thay đổi (bởi con hoặc cha mẹ), các thay đổi sẽ được sao chép và sau đó chỉ đến một vị trí mới.

Cho đến khi một trong các quy trình thực hiện thay đổi dữ liệu đó, họ sẽ chia sẻ cùng một bản sao. Kết quả là, tôi có thể có một quá trình sử dụng 100 MB RAM và chia nó 10 lần. Mỗi quá trình phân tách đó sẽ hiển thị 100 MB RAM đang được sử dụng, nhưng nếu bạn nhìn vào mức sử dụng bộ nhớ chung trên hộp, có thể chỉ cho thấy 130 MB RAM đang được sử dụng (100 MB được chia sẻ giữa các quy trình, cộng thêm vài MB chi phí , cộng thêm một tá MB hoặc hai cho phần còn lại của hệ thống).

Như một ví dụ cuối cùng, tôi có một hộp ngay bây giờ với 30 quy trình apache đang chạy. Mỗi quá trình đang hiển thị việc sử dụng 22MB RAM. Tuy nhiên, khi tôi chạy miễn phí -m để hiển thị mức sử dụng RAM tổng thể của mình, tôi nhận được:

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

Như bạn có thể thấy, hộp này thậm chí không có đủ RAM để chạy 30 quy trình, mỗi quy trình sử dụng 18 MB RAM "thực". Trừ khi bạn thực sự hết RAM hoặc ứng dụng của bạn bị tráo đổi mạnh, tôi sẽ không lo lắng về mọi thứ.

CẬP NHẬT: Ngoài ra, hãy kiểm tra công cụ này được gọi là smem , được đề cập bởi jldugger trong câu trả lời cho một câu hỏi khác về việc sử dụng bộ nhớ Linux tại đây .

Sử dụng sa-compile, bạn có thể cải thiện tốc độ khớp của nhiều quy tắc.

Đây là những gì tôi đã làm.

Tôi có một thiết lập trong đó rất nhiều tin nhắn có xu hướng được gửi cùng một lúc; đối với một loạt các thử nghiệm, tôi chạy SA trên các tin nhắn được sao chép vào một ống chỉ tạm thời và sau đó được gửi bởi một công việc định kỳ cứ sau năm phút.

spamd sẽ tiếp tục in "có lẽ bạn nên tăng tham số max-children" và tôi đã tăng nó lên tới 40 tại một thời điểm, nhưng tôi đã khiến máy chủ tiêu tốn hết dung lượng trao đổi và bị sập.

Bây giờ tôi đã thực hiện một chế độ khác trong đó việc phân phối được điều chỉnh bởi tệp khóa Procmail. Bởi vì nó rất đơn giản để thực hiện, tôi chỉ sử dụng chữ số cuối của ID tiến trình và chạy với 10 con. Tôi hoàn toàn không chắc chắn điều này là tối ưu, nhưng nó đã giúp tránh các đỉnh tải điên rồ mà tôi thỉnh thoảng trải nghiệm.

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

Ngoài ra, tôi bắt đầu spamdvới một số ulimithạn chế. Các số đã được lấy ra khỏi http://svn.apache.org/repose/asf/spamassassin/trunk/contrib/run-masses trừ khi tôi xóa bỏ ulimit -uhạn chế. (Không chắc chắn những gì đang diễn ra. 32 là quá nhỏ trong bất kỳ sự kiện nào. Với thứ gì đó như 500 tôi có thể tiếp tục spamdchạy trong một thời gian, nhưng cuối cùng lại chạy vào giới hạn.)

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

Tôi đoán rằng tôi sẽ kết thúc với thất bại giao hàng nếu tải quá cao trong thời gian dài, nhưng cho đến nay, có vẻ như tôi đã quản lý để giảm tải xuống mức có thể quản lý được với điều này; và một loạt các giao hàng thất bại vẫn còn tốt hơn nhiều so với máy hết trao đổi.

Trung bình tải cao là (đôi khi) một triệu chứng gián tiếp rằng máy của bạn sắp hết RAM (và sử dụng nhiều quá trình hoán đổi CPU qua lại từ bộ nhớ ảo), vì vậy bạn có thể thử định cấu hình máy chủ thư của mình để không chuyển thư qua SpamAssassin nếu tải trung bình quá cao.

Bạn không đề cập đến MTA nào bạn đang chạy, nhưng nếu bạn đang gọi SA từ danh sách kiểm soát truy cập trong exim4, thì đề xuất ở cuối thư này có hiệu lực.

Ngoài ra, bạn có thể giảm tải cho SA và do đó giảm mức sử dụng bộ nhớ của nó, bằng cách đặt một số phương pháp lọc thư rác ít tốn tài nguyên khác trước nó (nghĩa là chúng xử lý và từ chối một số thư rác trước khi đến SA) - ví dụ, greylning và người gửi xác minh chú thích sử dụng RAM tương đối ít.

Chúng tôi đã ở trong một tình huống tương tự vài tháng trước. SpamAssassin và ClamAV đã sử dụng nhiều bộ nhớ trên máy chủ được lưu trữ. Chúng tôi có tùy chọn thêm bộ nhớ vào máy chủ, nhưng hóa ra sẽ hiệu quả hơn về mặt chi phí và thời gian để chuyển sang Postini. YMMV.