On linux you can do something like this to /etc/security/limits and restart ldap: ldap soft nofile 32768 ldap hard nofile 65525

Robert

Jean-Francois Bouchard wrote:

Hello

I have an interesting issue here.

We are operating a grid ( http://en.wikipedia.org/wiki/Grid_computing ) composed of a bit more than 300 CPUs.

We have a standalone machine that take care of our LDAP server. Right now this machine run the LDAP server with a idletimeout set.

When a use submit a bunch of job (Lets say 10 000 jobs) each job generate a query to the LDAP machine. What happen ? The only process stop accepting connection due to the FD size limit (1024 connections). Even with a idletimeout connection set at 2 second...

What choice we have to let our LDAP machine do more ...

We like to know if openLDAP can do like apache (fork a process for each connection, or a process for a small bunch of connection.)

Thanks

---

Jean-Francois Bouchard

Jean-Francois Bouchard wrote:

Hi Robert,

Thanks for the response.

Some day I have tried :

ulimit -n (file handle) 65535

But at this point, socket become a problem. And I think for that we need to recompile the package with FS_SET_SIZE modified.

I am right ?

You didn't provide any information about the versions of the software you're using, so it's hard to say.

If you're using a 2.6 Linux kernel and OpenLDAP 2.3 then slapd will use epoll instead of select, and then FD_SETSIZE is irrelevant. Otherwise yes, you need to recompile with OPENLDAP_FD_SETSIZE defined to a larger number.

Thanks.

Robert Petkus wrote:

...

On linux you can do something like this to /etc/security/limits and restart ldap: ldap soft nofile 32768 ldap hard nofile 65525

Robert

Jean-Francois Bouchard wrote:

...

Hello

I have an interesting issue here.

We are operating a grid ( http://en.wikipedia.org/wiki/Grid_computing ) composed of a bit more than 300 CPUs.

We have a standalone machine that take care of our LDAP server. Right now this machine run the LDAP server with a idletimeout set.

When a use submit a bunch of job (Lets say 10 000 jobs) each job generate a query to the LDAP machine. What happen ? The only process stop accepting connection due to the FD size limit (1024 connections). Even with a idletimeout connection set at 2 second...

What choice we have to let our LDAP machine do more ...

We like to know if openLDAP can do like apache (fork a process for each connection, or a process for a small bunch of connection.)

Thanks

---

Jean-Francois Bouchard

Jean-Francois Bouchard wrote:

Hello,

Thanks for the response.

Sorry :

2.6.16.21-0.8-smp

openldap2-2.3.19-18.7

Its Novell Suse 10.

If I understand, I can use those ulimit on 2.3 version ?

Also I ear that setting OPENLDAP_FD_SETSIZE can have impact on performance.

I've tested select() with around 4096 active sessions, no noticable impact. Dunno how it responds at 32768. We've talked about dividing things up to allow multiple listener threads in those situations, but haven't implemented it. Unfortunately epoll's user interface isn't very efficient, regardless of the improvements it has under the kernel layer.

Still, the available test results I've seen about server performance with thousands of connections doesn't seem applicable to an LDAP server. I.e., web server traffic patterns don't really reflect the kind of patterns we see with slapd.

As a separate consideration, my little AMD X2 3800+ here can only process about 40,000 entries/second, so I'd imagine that response time would get pretty long with 10,000 or more active connections.