Quanah Gibson-Mount wrote:
--On Wednesday, March 22, 2006 3:16 PM -0800 Charles Stephens
<[EMAIL PROTECTED]> wrote:
Unfortunately, this is not possible since we can't easily reproduce the
problem and we have over 40 replicas in production. I guess my question
would be then what could cause this kind of behavior? I did notice that
it is only occurring on the 10 most loaded servers.
Hm, well, since there is no change in the underlying database between
2.3.11 and 2.3.20, it is simply an upgrade of the binaries (stop slapd,
update the software, restart slapd). I'm sure that would be somewhat
time consuming on 40 replicas, but it should be doable...
The code involved here is in modify_add_values function, in mods.c under
servers/slapd:
[ ... snip ... ]
So there are only *two* return paths out of here besides success, which
is what we must be hitting. They are both: LBER_ERROR_MEMORY.
So, basically, you are running out of memory.
The old MySQL docs give a strong warning about tuning server parameters
to use more than 2Gb RAM on 32-bit x86 architecture because glibc allows
the process heap to grow over thread stacks:
http://mysqld.active-venture.com/InnoDB_start.html
I wondered whether the same problem would apply to OpenLDAP,
particularly of idlcachesize was set too large and we ended up caching a
large number of IDLs.
Has anybody come across such a problem ?
Regards,
Nick.
