Stefan F?rster:
> While I certainly like the fact that Postfix becomes more and more
> "admin friendly" in that it now also logs warnings about performance
> issues, I'd like to know how many milliseconds a single request to
> update the temporary whitelist may take before a warning is emitted.
>
> Is it 100ms? I got exactly 882 messages like
>
> postscreen[5486]: warning: ps_dict_put: /var/lib/postfix/ps_cache.db update
> took 108 ms
>
> with values ranging from 101 to 147 within the last 24 hours on a
> moderately busy system.
You can stop the logging with "helpful_warnings = no". In the last
version I added database delay logging, because someone was using
postscreen on top of MySQL, with rather disastrous consequences.
I can test postscreen in the lab, or on tiny systems, but there is
only one way to find out how postscreen works in the real world.
That its by having people use it. So you are collecting the data
for me.
Postscreen is a single process that can eliminate the obvious bots
without wasting one smtpd process per SMTP client. But this works
only as long as postscreen does not block for any significant time
on database access (if every database access were to take 100ms,
postscreen could handle no more than 10 SMTP clients per second,
which would be worse than not using postscreen at all).
In your case, the slow operations appear to be writing to database,
which is done only when a client passes the pregreet etc. checks.
I could delete the "update delay" check safely.
I would be much more concerned if lookup operations were experiencing
delays, because those operations are much more common.
I could make the delay analysis more sophisticated and log delay
statistics every 10 minutes, with max/min/average/stddev, and
without sounding an alarm.
I could also take the OpenBSD spamd route, and use a kernel-based
packet filter to route "good" clients around postscreen. But, this
greatly increases the development effort because I would have to
maintain up-to-date packet filter documentation for Linux, FreeBSD,
OpenBSD, Solaris, and so on. That means dealing with all the variants
of ipchains, ipfilter and pf.
> Probably unrelated: When does postscreen(8) clean up it's database?
> Periodically? Every X connections? Never? What database sizes are to
> be expected?
The "delete old records" thread is not yet implemented. I suggest
that you rotate the cache file each Saturday night and do "postfix
reload" (the temporary whitelist entries are good for 24 hours
only, so deleting the file at a non-peak time has little impact).
Wietse
