On 26/11/2014 18:23, Ulrich Windl wrote:
What you could try is (assuming you have debug symbols in your
binary) attaching gdb to the running slapd to see where it is spending CPU time. I
can't remember the commands precisely, but "bt (backtrace)" and "info
threads" should point you in the right direction.
Note that slapd will likely stop responding while gdb is attached, so you could also try
to force a core dump for offline examination.
I'm not sure I follow here. How
would this work? I attach gdb to the
running slapd I get, but if it stops how does that help me? I've only
had a little bit of experience with gdb...
How would I get a core dump, as well? That sounds like it might be more
useful.
Maybe the gurus get a clue what may be wrong then...
Regards,
Ulrich
>>> Da Rock <openldap-technical(a)herveybayaustralia.com.au> schrieb am
26.11.2014 um
01:31 in Nachricht <54751F73.3080902(a)herveybayaustralia.com.au>:
> I'm trying to get openldap to play nice with mdb given that it is the
> "recommended" database backend for it now- although the conf wasn't an
> issue excepting I'm playing with the new cn=config setup we're expected
> to use now as well (even though it is mainly broken).
>
> My issue is that it seems to not respond like the older bdb/hdb
> databases. And when I say respond, I mean it hangs the ldapadd and makes
> slapd go into conniptions. I see slapd go to 100% WCPU and not come down
> as well as going into a uwait state. I've left it going for 10 minutes
> or more with no change, and I'm only adding 1 small entry of less the 10
> lines. Strangely, I can still view other entries in the specific db as
> well access the rest of the server, which I won't complain about (aren't
> threads a wonderful invention? ).
>
> So coming to the experts - got a fix at all? Or should I just go back to
> ye olde db backends? At this point I have a db I can't add anything to.
>
> And before anyone asks, there is practically nothing in the logs that I
> can see; and I set the logging to everything (-1). I see recognition of
> the user in the acl and then nothing. The only possible curious entry is
> some blank lines and a number (that changes each time), so nothing
> informative.
>
> I set it up using the cn=config (and I'm still not entirely convinced
> that I will keep cn=config, but apparently it could be gone next version
> according to the grapevine, so the consensus is to suck it up and get
> used to it or your panties will get in a bunch and around your ankles
> when the upgrade comes along), and I've got only olcDBMaxSize.
> olcSizeLimit (not sure exactly which of these 2 can go just yet),
> olcDBMode, olcDBDirectory, and olcDatabase and the obviously root attrs.
> My max size I've set larger than 50M (so 7 digits) which is larger than
> what I have in another db so far, and I figure I can add more if needed
> - currently it is sitting at 64k.
>
> I'm using FreeBSD 9.1, ports Openldap version is 2.4.40_1 with bdb/hdb
> and mdb set in config. But I notice lmdb is not installed as a
> dependency - is this right?
>
> I've been on this for near a week now with no further advancement so any
> help would be very welcome at this point. No googling seems to find
> anything remotely similar either.
>
> TIA