Cara meminimalkan penggunaan memori SpamAssassin (spamd)

Saya menggunakan SpamAssassin di Debian (konfigurasi default dengan Pyzor, AWL dan Bayes dinonaktifkan, dan sa-compile diaktifkan), dan setiap proses spamd anak mengkonsumsi sekitar 100 hingga 150MB memori (sekitar 50MB memori nyata) pada 32 server bit, dan sekitar dua kali lipat ini (cukup logis) pada server 64 bit. Pada umumnya ada dua proses anak, tetapi pada waktu sibuk mungkin ada lima (maksimum) yang berjalan.

ISTM yang 200 hingga 600MB adalah banyak memori untuk tugas ini. Saya ingin terus menggunakan SA sebagai bagian dari struktur penyaringan saya, tetapi menjadi sulit untuk membenarkan begitu banyak memori.

Adakah cara untuk mengurangi jumlah memori yang digunakan setiap proses anak? (Atau sebagai alternatif, buat proses satu anak begitu cepat sehingga saya dapat mengatur anak maksimum menjadi sekitar 2?). Saya bersedia mempertimbangkan opsi apa pun, termasuk opsi yang akan atau dapat mengurangi akurasi.

Saya sudah membaca halaman "Kehabisan Memori" pada SA wiki ; tidak ada gunanya. Pesan yang lebih besar dari 5 MB tidak dipindai dengan SA.

Saya pikir Anda salah memahami cara Linux melaporkan penggunaan memori. Ketika sebuah proses bercabang, itu menghasilkan proses kedua yang berbagi banyak sumber daya dengan proses aslinya. Termasuk di dalamnya adalah memori. Namun, Linux menggunakan teknik yang dikenal sebagai Copy On Write (COW) untuk ini. Apa artinya itu adalah bahwa setiap proses anak bercabang akan melihat data yang sama dalam memori sebagai proses asli, tetapi setiap kali data itu berubah (oleh anak atau orang tua), perubahan disalin dan hanya kemudian menunjuk ke lokasi baru.

Sampai salah satu proses membuat perubahan pada data itu, mereka berbagi salinan yang sama. Sebagai hasilnya, saya bisa memiliki proses yang menggunakan 100MB RAM, dan memotongnya 10 kali. Masing-masing proses bercabang akan menunjukkan 100MB RAM sedang digunakan, tetapi jika Anda melihat keseluruhan penggunaan memori pada kotak, itu mungkin hanya menunjukkan bahwa 130MB RAM sedang digunakan (100MB dibagi antara proses, ditambah beberapa MB overhead , ditambah lagi selusin MB atau dua untuk sisa sistem).

Sebagai contoh terakhir, saya memiliki kotak sekarang dengan 30 proses apache berjalan. Setiap proses menunjukkan penggunaan 22MB RAM. Namun, ketika saya menjalankan free -m untuk menunjukkan penggunaan RAM secara keseluruhan, saya mendapatkan:

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

Seperti yang Anda lihat, kotak ini bahkan tidak memiliki cukup RAM untuk menjalankan 30 proses yang masing-masing menggunakan 18MB RAM "nyata". Kecuali Anda benar-benar kehabisan RAM atau aplikasi Anda bertukar berat, saya tidak akan khawatir tentang hal-hal.

UPDATE: Juga, periksa alat ini disebut smem , disebutkan oleh jldugger dalam jawaban untuk pertanyaan lain tentang penggunaan memori Linux di sini .

Menggunakan sa-compile Anda mungkin dapat meningkatkan kecepatan kecocokan banyak aturan.

Inilah yang telah saya lakukan.

Saya memiliki pengaturan di mana banyak pesan cenderung dikirimkan secara kasar pada saat yang sama; untuk serangkaian percobaan saya menjalankan SA pada pesan yang disalin ke spool sementara dan kemudian dikirim oleh pekerjaan cron setiap lima menit.

spamd akan terus mencetak "mungkin Anda harus meningkatkan parameter max-anak" dan saya telah menaikkannya hingga 40 pada satu titik, tapi saya memiliki server yang menghabiskan semua ruang swap dan crash.

Sekarang saya telah menerapkan rezim yang berbeda di mana pengiriman diatur oleh file kunci Procmail. Karena mudah dilakukan, saya hanya menggunakan digit terakhir dari ID proses, dan dijalankan dengan 10 anak. Saya sama sekali tidak yakin ini optimal, tetapi telah membantu menghindari puncak beban gila yang saya alami dari waktu ke waktu.

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

Selain itu, saya mulai spamddengan sejumlah ulimitbatasan. Angka-angka itu dikeluarkan dari http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses kecuali saya menghapus ulimit -ubatasannya. (Tidak yakin apa yang sedang terjadi. 32 terlalu kecil dalam hal apa pun. Dengan sesuatu seperti 500 aku bisa terus spamdberlari untuk sementara waktu, tetapi akhirnya berlari ke batas.)

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

Saya kira saya akan berakhir dengan kegagalan pengiriman jika bebannya terlalu tinggi untuk waktu yang lama, tetapi sejauh ini, tampaknya saya telah berhasil mengurangi beban ke tingkat yang dapat dikelola dengan ini; dan banyak pengiriman yang gagal masih jauh lebih baik daripada mesin yang kehabisan swap.

Rata-rata beban tinggi (kadang-kadang) merupakan gejala tidak langsung bahwa mesin Anda kehabisan RAM (dan menggunakan banyak proses pertukaran CPU bolak-balik dari memori virtual), sehingga Anda dapat mencoba mengonfigurasi server email Anda agar tidak mengirimkan email melalui SpamAssassin jika rata-rata beban terlalu tinggi.

Anda tidak menyebutkan MTA mana yang Anda jalankan, tetapi jika Anda memanggil SA dari daftar kontrol akses di exim4, maka saran di bagian bawah pesan ini efektif.

Selain itu, Anda dapat mengurangi beban pada SA, dan dengan demikian mengurangi penggunaan memorinya, dengan meletakkan beberapa metode penyaringan spam lain yang kurang sumber daya intensif di depannya (yaitu sehingga mereka memproses dan menolak beberapa spam sebelum sampai ke SA) - misalnya, greylisting dan pengirim memverifikasi info menggunakan RAM yang relatif sedikit.

Kami berada dalam situasi yang sama beberapa bulan yang lalu. SpamAssassin dan ClamAV menggunakan banyak memori pada server yang dihosting. Kami memiliki opsi untuk menambahkan lebih banyak memori ke server, tetapi ternyata lebih hemat biaya dan waktu untuk beralih ke Postini. YMMV.