Claude, | RedHat Linux 9.0, all available patches applied | amavisd-new-20030616-p6, SpamAssassin version 2.60
You are not telling which MTA are you using. | The problem becomes known as the system was not more operable because of | nearly infinite swapping activities. "Out of memory" messages related to | amavisd appears on the console but login is not more possible. The | system must be booted in order to have a chance to log in. Before going deeper, a general remark: keep the number of content filtering processes reasonably low ($max_servers in amavisd.conf, and matching maxproc in Postfix or the number of queue runners in dual-sendmail setups). Some setups are hard to keep under control, like sendmail milter or Postfix smtpd proxy. | When amavisd was started, the amount of used memory was growing | continously while the amount of CPU time used varied. If the available | amount of memory was sufficient, amavisd started the children processes | some time later but | the large amount of used memory was not released. Some time later all | activities were blocked because no more memory was available. | Using gdb and lsof I could find that the problem occured while amavisd | had opened bayes_toks and bayes_seen. Later these files were not more used | but the memory space were not released. I was surprised to seen that | bayes_toks was very large, about 140 MB. I tryed to start sa-learn with | the debug and --force-expire options. sa-learn reported that the db | is fishy but continued to run. After some time sa-learn stopped but | bayes_toks was still very large. A new sa-learn run showed the same | behaviour. The problem disappeared only after I had deleted the | Bayes_* files. I hope the SA folks can help here. This shouldn't be happening. Might be causes by a corrupted database. It may be beneficial to rebuild the bayes database from time to time (#su amavis; sa-learn --rebuild --force-expire), especially if the database is suspect. | amavisd should take appropriate measures to release memory after the | starting procedure using SA. It normally does. Its virtual memory footprint can grow if you are processing large mail, as SA wants to process it in memory. The memory gets reused for the next mail, but the process virtual memory never shrinks. This is why it is not wise to change the $max_requests setting by much. It is also wise to put a limit on mail size in your MTA and/or keep the $sa_mail_body_size_limit at a reasonable value. Mark ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
