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.
Thanks,
Tim
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
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?
Cheers,
Tim
On 27/10/10 16:26, Dieter Kluenter wrote:
Tim Dycetjdyce@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
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 Dycetjdyce@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
openldap-technical@openldap.org