Bump.
Any advice would be most appreciated.
Thanks.
From: Terence Lau
Sent: Wednesday, 24 January 2018 9:59 AM
To: 'dovecot@dovecot.org' <dovecot@dovecot.org>
Subject: Out of memory on lmtp vsz_limit
Hi,
We've been getting these types or errors for quite a while now ...
Fatal: master: service(lmtp): child 63477 returned error 83 (Out of memory
(service lmtp { vsz_limit=4096 MB }, you may need to increase it)
... and these errors have been decreasing in occurrence as we increased the
default_vsz_limit. Which is good but I would like to get some advice on how I
could possibly eliminate the errors.
We have an internal smtp server (postfix 3.1.0) that has the config
"always_bcc=arch...@company.com<mailto:always_bcc=arch...@company.com>" over
lmtp. This mailbox is on a separate dovecot server with the following config
(please let me know if the full config is required):
# 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.13 (7b14904)
# OS: Linux 4.4.0-109-generic x86_64 Ubuntu 16.04.1 LTS ext4
default_vsz_limit = 4 G
mail_location = maildir:/home/vmail/%d/%n
protocols = " imap lmtp pop3"
service lmtp {
inet_listener lmtp {
port = 24
}
}
userdb {
args = username_format=%u /etc/dovecot/users
default_fields = uid=vmail gid=vmail home=/home/vmail/%d/%n
driver = passwd-file
}
protocol lmtp {
mail_plugins =
}
Since we discovered the errors, we've been increasing the default_vsz_limit to
1G, then 2G and now 4G (Server has 6GB of memory). These errors occur whenever
a large number of emails get sent around the same time to our smtp server.
This causes the dovecot server to start crunching CPU and Memory. Load average
goes through the roof and takes some time to come back down as the smtp queue
clears itself.
This mailbox is obviously very large but we have a script that runs daily to
delete any emails older than a month:
find /home/vmail/company.com/archive/new/ -type f -mtime +30 -exec rm {} \;
find /home/vmail/company.com/archive/cur/ -type f -mtime +30 -exec rm {} \;
Still, the mailbox has on average of just under 300,000 emails. No one
accesses this mailbox with an email client, not until we need to dig something
up. And this has only happen once. So the emails pretty much never get
read/process by a user.
Now that we've increased the default_vsz_limit to 4G, the occurrence of these
errors has reduced considerably. But they still happen occasionally. Short of
increasing the memory further, are there any other options I have?
Thanks.
