Displaying 4 results from an estimated 4 matches for "ldb_perf".
Did you mean:
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 '(&(...
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...