DBERROR: Cannot allocate memory
Rob Mueller
robm at fastmail.fm
Thu Dec 5 21:09:21 EST 2002
This is probably more a berkeley DB question, but I'm wondering if anyone
else has seen this. Every now and then we see this in our imap log.
Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR db3: Unable to allocate 4151
bytes from mpool shared region: Cannot allocate memory
Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR: mystore: error storing
<xxx at yyy>: Cannot allocate memory
They tend to come in batches together, but there doesn't seem to be that
much else in common as to when they appear
We're only using db3 (db3_nosync) for our deliverdb (skiplist for everything
else) so it's not critical, but I'd like to understand it and get rid of it.
I'm also wondering if messages that have this problem are ignored by sieve,
which seems to give up a bit too easily if there's any problem anywhere.
This tends to annoying people with forwarding rules...
At first I thought it might be a shared memory segment problem:
ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
From:
http://www.redhat.com/docs/manuals/database/RHDB-2.0-Manual/admin_user/kerne
l-resources.html
(which is more about postgresql tuning, but anyway...)
[root at server3 root]# echo 134217728 >/proc/sys/kernel/shmall
[root at server3 root]# echo 134217728 >/proc/sys/kernel/shmmax
ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 131072
max total shared memory (kbytes) = 536870912
min seg size (bytes) = 1
But that hasn't fixed the problem, or made any of the errors less common as
far as I can tell.
Just listing the actual shared segments shows
ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x42020062 0 root 666 4096 1
0x00000000 131073 root 600 46084 23 dest
Which suggests that it isn't a problem either.
Anyway, has anyone else experienced this, or know of a solution?
Rob
More information about the Info-cyrus
mailing list