[Samba] samba4 binddlz performance

Thomas Manninger DBGTMaster at gmx.at
Sat Dec 15 03:51:08 MST 2012


-------- Original-Nachricht --------
> Datum: Fri, 14 Dec 2012 09:06:42 +1100
> Von: Andrew Bartlett <abartlet at samba.org>
> An: Thomas Manninger <DBGTMaster at gmx.at>
> CC: samba-technical at lists.samba.org, mat at samba.org
> Betreff: Re: [Samba] samba4 binddlz performance

> On Thu, 2012-12-13 at 10:24 +0100, Thomas Manninger wrote:
> > -------- Original-Nachricht --------
> > > Datum: Thu, 13 Dec 2012 09:37:29 +0100
> > > Von: "Thomas Manninger" <DBGTMaster at gmx.at>
> > > An: mat at samba.org, samba-technical at lists.samba.org, DBGTMaster at gmx.at
> > > Betreff: Re: [Samba] samba4 binddlz performance
> > 
> > > H
> > > 
> > > -------- Original-Nachricht --------
> > > > Datum: Mon, 10 Dec 2012 01:13:00 -0800
> > > > Von: Matthieu Patou <mat at samba.org>
> > > > An: Thomas Manninger <DBGTMaster at gmx.at>, samba-technical
> > > <samba-technical at lists.samba.org>
> > > > Betreff: Re: [Samba] samba4 binddlz performance
> > > 
> > > > On 12/03/2012 06:40 AM, Thomas Manninger wrote:
> > > > > -------- Original-Nachricht --------
> > > > >> Datum: Fri, 23 Nov 2012 14:32:31 -0800
> > > > >> Von: Matthieu Patou <mat at samba.org>
> > > > >> An: samba at lists.samba.org
> > > > >> Betreff: Re: [Samba] samba4 binddlz performance
> > > > >> On 11/19/2012 07:11 AM, Thomas Manninger wrote:
> > > > >>> Hello,
> > > > >>>
> > > > >>> i am using samba4rc2.
> > > > >>>
> > > > >>> I have problems with the bind9 dlz module, i get very long
> response
> > > > >> times from interal queries.
> > > > >>> root at s-srv01:~# dig s-srv04.test.local @192.168.0.4
> > > > >>>
> > > > >>> ; <<>> DiG 9.8.0-P4 <<>> s-srv04.test.local @192.168.0.4
> > > > >>> ;; global options: +cmd
> > > > >>> ;; Got answer:
> > > > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64478
> > > > >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2,
> > > ADDITIONAL:
> > > > 1
> > > > >>>
> > > > >>> ;; QUESTION SECTION:
> > > > >>> ;s-srv04.test.local.         IN      A
> > > > >>>
> > > > >>> ;; ANSWER SECTION:
> > > > >>> s-srv04.test.local.  900     IN      A       192.168.0.4
> > > > >>>
> > > > >>> ;; AUTHORITY SECTION:
> > > > >>> test.local.           900     IN      NS     
> s-srv01.test.local.
> > > > >>> test.local.           900     IN      NS     
> s-srv04.test.local.
> > > > >>>
> > > > >>> ;; ADDITIONAL SECTION:
> > > > >>> s-srv01.test.local.  900     IN      A       192.168.0.1
> > > > >>>
> > > > >>> ;; Query time: 1239 msec
> > > > >>> ;; SERVER: 192.168.0.4#53(192.168.0.4)
> > > > >>> ;; WHEN: Mon Nov 19 16:07:59 2012
> > > > >>> ;; MSG SIZE  rcvd: 108
> > > > >> .local is normally used for mdns (see.
> > > > >> http://en.wikipedia.org/wiki/MDNS#Host_Discovery), can you try
> with
> > > > >> another kind of tld (ie. use domain test.corp).
> > > > >>> external queries are a little bit faster:
> > > > >>>
> > > > >>> root at s-srv01:~# dig google.com @192.168.0.4
> > > > >>>
> > > > >>> ; <<>> DiG 9.8.0-P4 <<>> google.com @192.168.0.4
> > > > >>> ;; global options: +cmd
> > > > >>> ;; Got answer:
> > > > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56403
> > > > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 13,
> ADDITIONAL:
> > > 6
> > > > >>>
> > > > >>> ;; QUESTION SECTION:
> > > > >>> ;google.com.                    IN      A
> > > > >>>
> > > > >>> ;; ANSWER SECTION:
> > > > >>> google.com.             300     IN      A       173.194.35.135
> > > > >>> google.com.             300     IN      A       173.194.35.136
> > > > >>> google.com.             300     IN      A       173.194.35.137
> > > > >>> google.com.             300     IN      A       173.194.35.142
> > > > >>> google.com.             300     IN      A       173.194.35.128
> > > > >>> google.com.             300     IN      A       173.194.35.129
> > > > >>> google.com.             300     IN      A       173.194.35.130
> > > > >>> google.com.             300     IN      A       173.194.35.131
> > > > >>> google.com.             300     IN      A       173.194.35.132
> > > > >>> google.com.             300     IN      A       173.194.35.133
> > > > >>> google.com.             300     IN      A       173.194.35.134
> > > > >>>
> > > > >>> ;; AUTHORITY SECTION:
> > > > >>> .                       45846   IN      NS     
> a.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> c.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> b.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> g.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> f.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> j.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> e.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> i.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> l.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> k.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> h.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> d.root-servers.net.
> > > > >>> .                       45846   IN      NS     
> m.root-servers.net.
> > > > >>>
> > > > >>> ;; ADDITIONAL SECTION:
> > > > >>> a.root-servers.net.     45846   IN      A       198.41.0.4
> > > > >>> b.root-servers.net.     45846   IN      A       192.228.79.201
> > > > >>> c.root-servers.net.     45846   IN      A       192.33.4.12
> > > > >>> d.root-servers.net.     45846   IN      A       128.8.10.90
> > > > >>> e.root-servers.net.     45846   IN      A       192.203.230.10
> > > > >>> f.root-servers.net.     45846   IN      A       192.5.5.241
> > > > >>>
> > > > >>> ;; Query time: 281 msec
> > > > >>> ;; SERVER: 192.168.0.4#53(192.168.0.4)
> > > > >>> ;; WHEN: Mon Nov 19 16:09:06 2012
> > > > >>> ;; MSG SIZE  rcvd: 511
> > > > >>>
> > > > >>>
> > > > >>> When i change to the samba4 internal dns server, i get response
> time
> > > > >> about ~1-2ms.
> > > > >>> But why is the bind dlz modul so slooow..?
> > > > >> you can use kcachegrind to trace bind in foreground mode in order
> to
> > > > see
> > > > >> where the time is spent.
> > > > >>
> > > > >> Matthieu.
> > > > >>
> > > > >> -- 
> > > > >> Matthieu Patou
> > > > >> Samba Team
> > > > >> http://samba.org
> > > > >>
> > > > >> -- 
> > > > >> To unsubscribe from this list go to the following URL and read
> the
> > > > >> instructions:  https://lists.samba.org/mailman/options/samba
> > > > > I started bind with:
> > > > >
> > > > > valgrind --tool=callgring /usr/sbin/named -c /etc/bind/named.conf
> -f
> > > > >
> > > > > So i get any answers, bind is very slow.
> > > > Yeah callgrind tends to slow down a lot but it's super useful.
> > > > >
> > > > > Now, i have a callgrind file, but i dont can read this file... I
> only
> > > > see, that ltdb_search_indexed needs incl. 96%..
> > > > >
> > > > > can somebody helps me??
> > > > >
> > > > > file is included as attachment.
> > > > >
> > > > > thanks!
> > > > 
> > > > Sorry I'm just able to have a look at it now, so yes most of the
> time is
> > > > spent in the ltdb_search_indexed.
> > > > 
> > > > Looking at the code and the capture in the dlz_bind9.c it seems that
> the
> > > > function dlz_lookup_types is call 44 times and is doing 44
> ldb_search 
> > > > with a base scope on a given DN.
> > > > Those 44 search yield 144 calls to the ltdb_search and given the
> fact 
> > > > that we ends up with 147862 calls to ltdb_search_dn1 I'm highly sure
> > > > that not all the internal searches where done with a base scope 
> > > > (otherwise we would have 144 calls to ltdb_search_dn1).
> > > > 
> > > > The initial search for me looks perfect and there is no real
> possibility
> > > > to make it any better scope=base + specified dn is the ideal case
> imho.
> > > > 
> > > > I'm looking at a small optimization in the LDB indexing to save DNs
> in 
> > > > the index already case_folded which should help quite a lot as you
> spent
> > > > half of the time doing this kind of operation.
> > > > Another way to improve this is to understand why we have a spread of
> > > > ltdb_search calls and why some of those calls seems to be with a
> subtree
> > > > scope.
> > > > 
> > > > Could you rebuild the library with make clean;
> ./configure.developper; 
> > > > make -j and is it possible to share your database ?
> > > > 
> > > > Thanks.
> > > > 
> > > > Matthieu
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Matthieu Patou
> > > > Samba Team
> > > > http://samba.org
> > > > 
> > > 
> > > When i delete all user and groups, i can share my database. its ok?
> > 
> > And how can i delete all users and groups completely??
> 
> This is quite difficult to do, and if the situation is as you describe,
> then it would probably resolve your issue anyway. 
> 
> Better would be to re-create a testing domain with similar
> characteristics - eg lots of users, groups and DNS entries.
> 
> Andrew Bartlett
> 
> -- 
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> 
> 

Now, i dont unterstand, how can i resolve my problem ...

Regards,
Thomas


More information about the samba-technical mailing list