* Wietse Venema <wie...@porcupine.org>: > Stefan Foerster: > > 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.
That's perfectly fine for me. If you need more data (e.g. update time in correlation to DB size, distribution of wait times), please don't hesitate to ask. > 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 don't know about other users' opinion, but personally I don't think those data would be too interesting. With "real" databases, on can gather performance data at the database level. If OTOH, the database type used for the postscreen database is known to deteriorate performance-wise if it's size exceeds a certain threshold (be it entries or bytes), then a warning would be most welcome if that threshold is exceeded. > > 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). Can I simply truncate the file as in sh# > /var/lib/postfix/ps_cache.db before reloading Postfix? If done correctly, what other impact besides possibly delaying clients previously known as "good" are to be expected? Stefan
