Re: ldapsearch performance degradation

["Dieter Kluenter" <dieter@dkluenter.de>]

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
networks.

-Dieter

>
> 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 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6