[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapsearch performance degradation

Tim Dyce <tjdyce@unimelb.edu.au> writes:

> Thanks Deiter,
> I've tried that but as attached, the problem is the same :(
> Any other ideas? I'm tempted to try the mysql backend just to test if
> it's not BDB, does anyone have a good guide for that?

The sql backend, and thus MySQL, is much slower than the bdb backend.
As slapd is running within a virtual machine and network, you should
focus on filesystem, virtual hardware and such. I have experienced
rather strange phenomenon with regard to virtual machines and


> On 27/10/10 16:26, Dieter Kluenter wrote:
>> Tim Dyce<tjdyce@unimelb.edu.au>  writes:
>>> Hi all,
>>> I am trying to track down what causes ldap searches to slow down over
>>> time, especially if content is added and removed. We are having issues
>>> with this as a grid site in the EGEE/EGI computing grid.
>>> Attached is a graph of search performance over time, and a basic test I
>>> did to get it (runs from  /opt/bdii_test_core). This test only uses the
>>> core schema and operates on organizationalUnit.
>>> Can anyone tell me what's causing this?
>>> It's causing us some serious grief, as the searches slow down, some
>>> sites start to disappear off the grid and jobs start to fail.
>>> I've tried restarts and slap_index, but no love.
>>> Any help/advice would be much appreciated.
>> Is there any particular reason to increase the thread pool to 256?
>> Just stick to the default of 16, this will most likely increase
>> performance.
>> -Dieter

Dieter Klünter | Systemberatung
sip: 7770535@sipgate.de