ο spamassassin αργεί φρικτά και δεν μπορώ να δω γιατί
George Notaras
gnot at g-loaded.eu
Tue Apr 28 15:55:13 EEST 2009
Nick Demou wrote:
> κάθε μήνυμα που περνά από το spamassassin απαιτεί 15sec και μερικά
> πολύ περισσότερα και ψάχνω να βρω τι μπορώ να κάνω για να μειώσω το
> χρόνο (τα 15sec είναι κατά 99% idle time - δεν έχω ούτε cpu ουτε I/O).
> Το 2ο και μεγαλύτερο πρόβλημα μου είναι ότι δεν καταφέρνω να δω debug
> μηνύματα απο το spamd για να καταλάβω που χάνει τον περισσότερο χρόνο.
> Έχω επιβεβαιώσει ότι κατάφερα να ξεκινά το spamd με το switch -D [1]
> αλλά παρόλ' αυτά δεν βλέπω κανένα debug line στο /var/log/mail.info.
> Ορίστε ένα παράδειγμα του τι βλέπω (και τώρα και πριν το -D):
>
> Apr 28 12:28:56 lolita spamd[12233]: prefork: child states: II
> Apr 28 12:28:56 lolita spamd[12920]: spamd: connection from localhost
> [127.0.0.1] at port 53574
> Apr 28 12:28:56 lolita spamd[12920]: spamd: setuid to fetchuser succeeded
> Apr 28 12:29:00 lolita spamd[12920]: spamd: processing message
> <000d01c9c768$9d1b7b80$6400a8c0 at hypnotizesqi8> for fetchuser:1003
> Apr 28 12:30:11 lolita spamd[12920]: spamd: identified spam (14.5/5.0)
> for fetchuser:1003 in 75.0 seconds, 19535 bytes.
> Apr 28 12:30:11 lolita spamd[12920]: spamd: result: Y 14 -[...]
> scantime=75.0,size=19535,user=fetchuser,uid=1003,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=53574,mid
> =<000d01c9c768$9d1b7b80$6400a8c0 at hypnotizesqi8>,bayes=1.000000,autolearn=spam
>
>
> Έτρεξα caching dns στο ίδιο pc (bind) και έχω επιβεβαιώσει ότι
> λειτουργεί κανονικά (δοκιμάζοντας με dig) αλλά οι χρόνοι έμειναν οι
> ίδιοι και χειρότεροι.
>
> Διάβασα στο site "do some tests with Net::DNS to make sure it is
> resolving names" αλλά δεν κατάφερα να βρω πως δοκιμάζουν το Net::DNS
> (δεν γνωρίζω γρι απο perl). Επίσης διάβασα "A common mistake [...] is
> to have 127.0.0.1 in the </etc/resolv.conf> file -- Net::DNS does not
> check multiple nameservers it appears, so you need to comment this
> line out for Net::DNS to work" το οποίο δεν το καταλαβαίνω (εγώ έχω
> την γραμμή "nameserver 0.0.0.0" στο resolv.conf και μου φαίνεται πολύ
> λογικό αφού τρέχω το bind ως caching name server)
>
> Να σημειώσω πως έχω δύο εγκαταστάσεις με πρακτικά το ίδιο setup εκ των
> οποίων μόνο η μία παρουσιάζει το πρόβλημα (έχω κάνει ελάχιστες αλλαγές
> στο default setup -- για την ακρίβεια πείραξα μόνο τα απολύτως βασικά
> γιατί το documentation του spamassasin μου μοιάζει ένα chaotic work in
> progress).
>
>
> [1] όντας σε ubuntu (όσον αφορά το spamassasin ίδιο ή σχεδόν ίδιο
> setup με debian) έχω προσθέσει το switch -D στο
> /etc/default/spamassassin (στο OPTIONS)
>
Αντιμετώπιζα πρόβλημα με μεγάλη αργοπορία στο processing των emails από
το spamassassin, με αποτέλεσμα τα emails να παραμένουν στο queue του
postfix.
Επειδή έχει περάσει καιρός κι επειδή εδώ κι έξι μήνες έχω μεταπηδήσει
στο bogofilter, τώρα δεν μπορώ να θυμηθώ τις ακριβείς αιτίες του
προβλήματος με το SA. Τα παρακάτω τα γράφω με βάση κάποια σχόλια που
είχα σημειώσει μέσα στο config.
Μέσες άκρες, το πρόβλημα είχε να κάνει κυρίως με το auto-learning και τη
δημιουργία πολλών tokens που δημιουργούσε η χρήση του, με το γεγονός ότι
τα νέα tokens αποθηκεύονταν αρχικά σε κάποιο journal αντί για το κυρίως
bayes database, με το αυξημένο μέγεθος αυτού του journal, με το γεγονός
ότι το SA προσπαθούσε να κάνει expire στα old token files ενώ παράλληλα
κρατούσε locked τη bayes database. Όλα αυτά είχαν ως αποτέλεσμα να
παραμένει locked η bayes db για μεγάλο διάστημα και να μην
πραγματοποιείται το processing των emails (ίσως λόγω κάποιων timeouts κτλ)
Ρίξε μια ματιά στα παρακάτω:
http://wiki.apache.org/spamassassin/ManyBayesToksExpireFiles
http://wiki.apache.org/spamassassin/BayesForceExpire
Επίσης, απ' ότι βλέπω έτρεχα το παρακάτω cronjob μία φορά την ημέρα,
αλλά (ως κάφρος) δεν είχα γράψει ούτε ένα αναλυτικό σχόλιο:
#! /usr/bin/env bash
#
# Manual Bayes Expire
#
/etc/init.d/spamassassin stop
time su spamd -c "sa-learn -D --force-expire"
/etc/init.d/spamassassin start
sleep 20
/usr/sbin/postqueue -f
Επίσης, για κάποιο διάστημα είχα προσθέσει τα παρακατω options στο spamd
για τη συλλογή των debug messages σε ξεχωριστό αρχείο:
-D -s /var/lib/spamassassin/spamd.log
Το ότι συμβαινει στη μία μόνο εγκατάσταση του SA ίσως να οφείλεται στον
διαφορετικό αριθμό emails που διαχειρίζεται η καθεμία.
Όλα αυτά τα γράφω με επιφύλαξη και απλά για να χρησιμοποιηθούν ως
starting points και όχι ως αυτούσιες λύσεις. Μπορεί σε εσένα να
οφείλεται κάπου αλλου το πρόβλημα, αλλά η περίπτωση που περιγράφεις μου
θύμισε έντονα το πρόβλημα που αντιμετώπισα εγώ με το SA, για το οποίο
είχα ξοδέψει αρκετές ημέρες και που ήταν μία από τις αιτίες που με
ανάγκασαν να μεταπηδήσω σε άλλο spam filter.
More information about the Linux-greek-users
mailing list