[Date Prev][Date Next]
Re: ldapsearch performance degradation
Tim Dyce <email@example.com> 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<firstname.lastname@example.org> 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
Dieter Klünter | Systemberatung
GPG Key ID:8EF7B6C6