search for: ldb_perfs

Displaying 4 results from an estimated 4 matches for "ldb_perfs".

2015 Nov 23
2
samba4 ldap high load and port queue overflow
Hi all. I have samba 4.2.3 on freebsd 10.1 server. There are three DC and about 350 PC on domain. DCs have 3 CPU and 3GB RAM. Some servers with services like apache, exim, dovecot, etc use samba4 ldap (port 389) for user authentication. Some times ago after adding some services to use ldap I found, that samba4 cannot serve all ldap requests. Every 10-30 minutes I see in DCs logs: dc1 kernel:
2015 Nov 25
0
samba4 ldap high load and port queue overflow
...mple, until recently we had a 'prefork' process mode, that would allow for example once LDAP process per port. It hasn't ever been used in that combination, but interested parties could put it back, add a test and see if it helps. More likely to help (but more effort) are merging the ldb_perfs branch, profiling the rest of the code in search of performance issues, replacing the ldb_tdb backend with ldb_lmdb. However, I would go back to looking at the sources of the queries - if your DB is constantly under full-DB scan, it will very likely show symptoms like you see. Thanks, Andrew...
2014 Sep 30
2
Samba 4 LDAP/LDB search speed
...es about 2.5 seconds, with Samba 4 it takes around 30 seconds. This is with samba 4.1.11, ldb 1.1.17. The database has around 300 entries, not following the returned references. I've tried using Matthieu Patou's patches from http://git.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/ldb_perfs on my ldb, but that did not notably change the speed (which might very well be that I am not testing correctly). Thanks for any info on this! Regards, Roel #!/bin/sh for i in `seq 1 1000`; do ldapsearch -x -h localhost -p 389 -D cn=dago,cn=Users,dc=s4,dc=local \ -w password '(&(o...
2015 Nov 26
2
samba4 ldap high load and port queue overflow
...had a > 'prefork' process mode, that would allow for example once LDAP process > per port. It hasn't ever been used in that combination, but interested > parties could put it back, add a test and see if it helps. > > More likely to help (but more effort) are merging the ldb_perfs branch, > profiling the rest of the code in search of performance issues, > replacing the ldb_tdb backend with ldb_lmdb. > > However, I would go back to looking at the sources of the queries - if > your DB is constantly under full-DB scan, it will very likely show > symptoms like...