On Thursday 09 February 2006 12:15, Quanah Gibson-Mount wrote: > --On Thursday, February 09, 2006 11:25 AM -0500 matthew sporleder > > <[EMAIL PROTECTED]> wrote: > >> > I've reproduced this behavior, it's due to the same reason as > >> > ITS#4385. Now fixed in HEAD back-bdb/cache.c. A potential workaround > >> > is to issue a few no-op requests to the slapd server while the large > >> > search operation is in progress. (Basically the task that purges > >> > excess entries from the entry cache isn't getting started right away; > >> > it won't start until the current search finishes or any new request is > >> > received.) You can use this patch: > > > > Is this 32bit linux specific, or will it affect all larger databases? > > The patch looks very simple, but I was just wondering about the impact. > > It is not 32 bit linux specific. However, as noted above by Howard, it > only is going to affect a system that has a single search occurring on it. > I.e., if your LDAP server is a busy one, then you won't notice this > behavior. As soon as a second operation (search, bind, mod, add, etc) is > received, then the task that purges excess entries kicks in. Which is > likely why no one noticed this previously. >
All of this seems true from my observations. It should be noted that if you are searching for a large number of entries on a server that has no load, you will see all operations to that server hang when you initiate the second operation (as I assume the purge task is taking a fair amount of time to complete). This is apparently what was happening on my 12MB BDB cachesize example. As expected, there is no hang with the patch in place. dave
