If gdb is attached to the process ("attach <PID>"), you can examine the CPU registers and the memory. Specifically the call stack. If a specific routine uses all the CPU, it's very likely that gdb will find that active routine and where it was called from. Together with local variables (info locals), a developer could find out what's wrong. Maybe you'll have to combine "-g" with "-O0" for more reliable results.
You'll get a coredump by something like kill -BUS <pid> (check ulimit -c also before starting the process), and you can detach gdb from the process after inspection.
Da Rock openldap-technical@herveybayaustralia.com.au schrieb am 26.11.2014 um
10:41 in Nachricht 5475A053.7060209@herveybayaustralia.com.au:
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@herveybayaustralia.com.au schrieb am 26.11.2014 um
01:31 in Nachricht 54751F73.3080902@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