Re: slow memberOf queries in 2.5 with dynlist overlay
On Mon, Feb 14, 2022 at 06:01:43PM -0800, Paul B. Henson wrote:
On Mon, Feb 14, 2022 at 09:57:06AM -0800, Quanah Gibson-Mount wrote:
> How large is the total size of all mdb databases?
[...]
So a total of a bit over 2GB.
> How much RAM do you have on the system?
2GB. I don't think I'm running low on memory, there's usually a bit
free:
# free -m
total used free shared buff/cache available
Mem: 1949 423 79 0 1446 1372
Swap: 1023 291 732
And when it's being really slow for memberOf there's no swapping or other
signs of low memory. Other queries are still very responsive, it's just
memberOf that gets slow. The only metric that seems ramped when it occurs
is high read IO.
So think about it:
- your DB is just over the size of available RAM by itself
- after a while using the system, other processes (and slapd) will carve
out a fair amount of it that the system will be unwilling/unable to
page out
- if, to answer that query, you need to crawl a large part of the DB,
the OS will have to page that part into memory, at the beginning,
there is enough RAM to do it all just once, later, you've reached a
threshold and it needs to page bits in and then drop them again to
fetch others you develop these symptoms - lots or read I/O and a delay
in processing
Figure out what is involved in that search and see if you can tweak it
so it doesn't need to crawl the whole DB or make sure you always have
enough RAM to page the whole DB in, even when the other processes have
been running for a bit.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP