Managing memory
DBMail like many applications rely on external libraries. Although DBMail has been rigorously debugged over many years, with over forty dependencies it's inevitable there will be memory leaks. Fixing leaks is an ongoing effort. Bug reports, particularly with a test email and IMAP commands to reproduce the issue are always welcome. Valgrind reports are a big plus.
Depending on your requirements, it may be better to manage memory usage until all memory leaks are fixed. Nagios and similar tools have check_procs to monitor memory and restart services.
For example:
- Warning 1Gb
- Critical 2Gb
- Metric VSZ (virtual memory size)
- Command dbmail-imapd
check_procs -w 1024000 -c 2048000 -m VSZ -C dbmail-imapd
Produces the following output if memory is below the warning threshold
VSZ OK: 1 process with command name 'dbmail-imapd' | procs=1;;;0; procs_warn=0;;;0; procs_crit=0;;;0; procvsz=248768;
The following is above the warning threshold, but below critical.
VSZ WARNING: 1 warn out of 1 process with command name 'dbmail-imapd' | procs=1;;;0; procs_warn=1;;;0; procs_crit=0;;;0; procvsz=248768;
The following output is above the critical threshold
VSZ CRITICAL: 1 crit, 0 warn out of 1 process with command name 'dbmail-imapd' | procs=1;;;0; procs_warn=0;;;0; procs_crit=1;;;0; procvsz=248768;
After monitoring your system you should be able to identify a suitable warning and critical range to balance minimal intervention for your available memory. Then an event handler can restart the service.
