[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Antw: Cannot add to mdb
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
>>
>>
>>