> Hi, > > I recently put my first spamd installation into production and am > quite impressed with the results, good work, folks. Nevertheless I > have some questions: > * it seems that when spamd scans it's database in /var/db/spamd (which > is currently ~160MB of size) it doesn't accept any new requests on > it's port (at least it let's the clients wait). That sucks. I see 2 > spamd processes process states hanging in: biowait, pipewr - I > understand that while the database is being scanned (and maybe locked) > new requests maybe can't easily be written to the db, is there a plan > to improve that (by creating a queue-log or something)? > * Due to the fact that spamd only seems to insert pf-rules into the pf > spamd-white table when doing a db-scan it seems that it creates some > more delays than necessary in the greylisted mta's. Let's say I have 2 > mx'es - mx1 and mx2 - my client is connecting to mx1, get's > greylisted, connects to mx2 (protected by the same spamd instance), > still keeps being greylisted - so my client adds a penalty time of > let's say 2x5 mins. After 10 minutes it connects to spamd again, tries > mx1, still gets redirected to spamd, but spamd decides to whitelist > that host, and writes that into the spamdb. After being refused for > mx1, my client tries mx2, and due to the fact that maybe spamd didn't > scan the spamdb yet the pf-rules aren't in place yet, so it get's > redirected to spamd once again, creating quite some penalty time of > let's say 2x10 minutes, which wouldn't be necessary if spamd would > insert that ip directly into pf on writing the whitelist-entry into > the database. Are there plans to improve that? > > I hope this is a question that still belongs to tech and not > developer, but I'm not too sure about that :) > > btw: I recorded 1886206 connections within the first 24 hours to spamd > for that particular mai provider :)
During the dbscan there is more than only replace the pf tables, so the db will opend with O_EXLOCK. - expired records are removed from the db (operates on the db) - new records are whitelisted (operates on the db) - pf table is rebuild You can see this if you run spamd in debug mode. Test it on another machine with a copy of your spamd db and watch the output. Normally the scan (every 60s) takes only a view seconds and it rarely that the same client connects exactly in this moment. >From your description it seems you run spamd with low priority MX support at a single machine. To get a better behavior either stop using low prio MX support which results in only one connect from the client or setup a second machine so you can use low prio support. Example. mx1 and mx2 with prio 10 are pointing to machine 1/2 to spamd with sync support. mx3 (mx4) with prio 100 pointing to the second ip (low prio mx trapp) at machine 1/2 This way the you have a redundant spamd setup and the db's between the machines are in sync. Regards, olli
