I have not reproduced your exact problem. However I did find [1] which
seems possibly relevant, and I can reproduce the original bug with ldclt
as in [2] in Debian (with slapd as server). I also experimented with a
slapd config containing 5 syncrepl clients, all using GSSAPI, and
encountered a
Sorry for the delay.
Server is:
VM with 8 vCPU (ESXi 5.5 hypervisor) host server is with 2*6 physical
core. VM has 6GiB RAM.
During normal operation: no significant CPU usage, each vCPU is below 5
percent, with peaks around 15 percent.
I attached partial config about the databases ( olcAccess a
On Sun, Apr 23, 2017 at 09:34:00AM +0200, GALAMBOS Daniel wrote:
Which I forgot to mention is that the slapd process uses one CPU core to
100 percent when this happens.
Noted. But you don't observe that CPU usage during normal operation? I'm
assuming this loop gets triggered when you ask slapd
Hi,
Which I forgot to mention is that the slapd process uses one CPU core to
100 percent when this happens.
We use Heimdal, so I installed cyrus-sasl2-dbg,cyrus-sasl2-heimdal-dbg
(i didn't notice the missing symbols from the first stacktrace)
Syncrepl happens with GSSAPI authentication.
I had
Control: tag -1 moreinfo
Hi,
On Sat, Apr 22, 2017 at 12:47:19PM +0200, GALAMBOS Daniel wrote:
I created a core file from the stuck process.
GDB backtrace attached as separate files.
Thanks for including the backtrace, that makes our job a lot easier. :)
Thread 2 (Thread 0x7f312f7fe700 (LWP
5 matches
Mail list logo
