Re: ldapsearch stalling when performing searches with a large number of results

On 26 Sep 2012, at 22:36, Quanah Gibson-Mount wrote: Which one in particular? I thought the set_cachesize had an upper limit of 4GB but your guidance on the Zimbra website suggests this is an old limit and I now can't find the page on the OpenLDAP site which discusses it. Alternatively would increasing the number of caches from 2 to 2 or 3 be a suitable workaround? Given that I've got a relatively healthy amount of RAM available would the following sound sensible to you olcDbCacheSize: 1000000 olcDbIDLcacheSize: 1200000 set_cachesize 4 0 2 I also want to give a bit of headroom for new user accounts (approx rate of increase 80,000/y) and creating a group object for each user. I've looked at your guidance on using SHM keys but I'm slightly reluctant to start playing around with kernel settings on production servers :-) The existing default settings on RHEL 5 seem massive in comparison though: kernel.shmmax = 68719476736 kernel.shmall = 4294967296 Whereas based on the ZImbra performance tuning page I calculated (based on 8GB BDB cache size + 0.5GB for other stuff) shmall would be: 2228224 and shmmax: 8589934592 Both of which appear to be an order of magnitude smaller than the defaults! Then there appears to be some Zimbra-specific commands but I'm guessing the equivalent is just setting the olcDBShmKey in slapd.d on vanilla OpenLDAP? My plan in the longer term is to move to MDB but when I tried it out on one of our test VMs (40GB HD) it pretty much devoured all available disk space. Is there a rule of thumb for deriving probable MDB disk space requirements based on existing BDB size? Thanks for the help and apologies for all the additional questions! Kind regards, Mark -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.