>>> "Paul B. Henson" schrieb am 22.05.2022 um 04:51 in
>>> Nachricht
<5d343067-aef3-b499-63e3-996f3d680...@acm.org>:
> On 5/11/2022 3:48 AM, Soisik Froger wrote:
>
>> Are this performance issues an expected side-effect of switching to
>> dynlist - as the memberOf attributes are now dynamically calculated
>> while the memberOf overlay used to writes these attributes - or
>
> I am also having ongoing sporadic issues with memberOf performance using
> the new dynlist overlay. Initially, randomly a server would get into a
> state where any query requesting the memberOf attribute would take in
> excess of 30 seconds, whereas normally it would only take a fraction of
> a second. The symptoms were the same, free memory, no swapping, but
> insanely high read IO load.
I'm wondering: If you'd make a core dump when the issue happens, how big would
such a core dump be with MDB?
I'm afraid it would be insanely large, containing the whole database. Am I
wrong?
>
> I cranked up the memory, which not did resolve the issue, but did help,
> it doesn't happen nearly as often. But still, every now and again, a
> server demonstrates a high read IO rate and severely degraded memberOf
> query performance. At this point, I just have a monitoring check that
> alerts on slow query performance and high read I/O and go restart them
> when it happens, as the additional memory made the issue go from a
> couple of times a week to every month or three.
>
> I did notice now that when the issue occurs the box with the slow
> queries does have less memory available then when it is working
> normally, but still a good gigabyte of free memory not being used.
>
> Even when the systems don't completely blow up, there are occasional
> slower than normal queries. Typically the test query I am doing
> literally takes fractions of a second:
>
> May 21 19:47:22 ldap-01 slapd[1223]: conn=849157 op=1 SEARCH RESULT
> tag=101 err=0 qtime=0.15 etime=0.198042 nentries=1 text=
>
> Every now and again for no discernible reason it might take 5 to 10 seconds.