Re: dnsperf and BIND memory consumption
Hello!
I test patch, add to bind95/Makefile
.if (${ARCH} == "amd64")
ARCH= x86_64
.endif
work/bind-9.5.0-P2/config.log
uname -m = amd64
/usr/bin/uname -p = amd64
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
ISC_ARCH_DIR='x86_32'
build='x86_64-portbld-freebsd7.0'
build_alias='x86_64-portbld-freebsd7.0'
build_cpu='x86_64'
host='x86_64-portbld-freebsd7.0'
host_cpu='x86_64'
I didn't find any affect, memory leak very quickly with threads support,
and slowly without threads.
FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 2 14:18:35 MSD
2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/H1 amd64
Vinny Abello wrote:
>>> so does this memory leak only occur if
>>> @ISC_ARCH_DIR@ is "noatomic" under FreeBSD amd64?
>>> and not when its "x86_32" ?
>> First off, note that I have no explicit evidence of memory leak. But
>> *if there is indeed leak in the FreeBSD pthread library*, the key is
>> "noatomic". With this configuration named will call pthread
>> locks/unlocks much, much heavier, so the problem may be observable
>> more clearly. named still uses pthread locks Even with x86_32, so it
>> may just be leaking memory more slowly.
>>
>> Again, everything is just a guess and could be wrong. We should seek
>> advice from someone who knows FreeBSD library well.
>
> Just out of curiosity, why in theory is this not seen in prior versions of
> BIND such as 9.4.2-P2 or 9.4.3 on the same FreeBSD 7.0 AMD64 platforms with
> threading enabled in BIND?
--
Рыбин Дмитрий
Управление магистральной сети
Отдел Информационных Систем
Руководитель группы АВР
Corbina Telecom
Tel: +7(495) 728-4000
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
Hi
can you verify if you're using the newly installed named.
did you configure your options to replace the base?
can you give us:
ldd /usr/sbin/named
ldd /usr/local/sbin/named
to my understanding, there should be no memory leak issue at all if you disable
threads..
this post has always been directed to the concern of FreeBSD + amd64 platform +
FreeBSD port dns/bind95 (BIND 9.5.0-P2) + threading enabled
thanks!
--- On Wed, 12/10/08, Dmitry Rybin <[EMAIL PROTECTED]> wrote:
> From: Dmitry Rybin <[EMAIL PROTECTED]>
> Subject: Re: dnsperf and BIND memory consumption
> To: "Vinny Abello" <[EMAIL PROTECTED]>
> Cc: "JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL
> PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Wednesday, December 10, 2008, 4:05 AM
> Hello!
>
> I test patch, add to bind95/Makefile
> .if (${ARCH} == "amd64")
> ARCH= x86_64
> .endif
>
> work/bind-9.5.0-P2/config.log
> uname -m = amd64
> /usr/bin/uname -p = amd64
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> ISC_ARCH_DIR='x86_32'
> build='x86_64-portbld-freebsd7.0'
> build_alias='x86_64-portbld-freebsd7.0'
> build_cpu='x86_64'
> host='x86_64-portbld-freebsd7.0'
> host_cpu='x86_64'
>
> I didn't find any affect, memory leak very quickly with
> threads support,
> and slowly without threads.
>
> FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 2
> 14:18:35 MSD
> 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/H1 amd64
>
>
> Vinny Abello wrote:
>
> >>> so does this memory leak only occur if
> >>> @ISC_ARCH_DIR@ is "noatomic" under
> FreeBSD amd64?
> >>> and not when its "x86_32" ?
> >> First off, note that I have no explicit evidence
> of memory leak. But
> >> *if there is indeed leak in the FreeBSD pthread
> library*, the key is
> >> "noatomic". With this configuration
> named will call pthread
> >> locks/unlocks much, much heavier, so the problem
> may be observable
> >> more clearly. named still uses pthread locks Even
> with x86_32, so it
> >> may just be leaking memory more slowly.
> >>
> >> Again, everything is just a guess and could be
> wrong. We should seek
> >> advice from someone who knows FreeBSD library
> well.
> >
> > Just out of curiosity, why in theory is this not seen
> in prior versions of BIND such as 9.4.2-P2 or 9.4.3 on the
> same FreeBSD 7.0 AMD64 platforms with threading enabled in
> BIND?
>
>
> --
> Рыбин Дмитрий
> Управление магистральной сети
> Отдел Информационных Систем
> Руководитель группы АВР
> Corbina Telecom
> Tel: +7(495) 728-4000
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
can't see nameserver externally
Hello, I noticed that one of our nameservers is no longer responding with the correct address externally. The server is ns-2.hosp.utmck.edu and is listed as a server in the registration record for utmck.edu. The address should be 165.6.6.27 but a dig/nslookup from an external site returns 165.6.144.1. We do not have 165.6.144.1 in any of the zone files, but this address is the external address of a broadband service manager in our network. Using dig/nslookup on the local network verifies that 165.6.144.1 is not in the zone files or cache of our nameservers. The name and address of our ns-2 resolve correctly internally. Can someone please tell me how to identify and correct this problem. $ORIGIN edu. utmck IN NS ns-2.hosp.utmck.edu. IN NS harley.mc.utmck.edu. IN A 165.6.57.12 IN MX 10 chewy2.mc.utmck.edu. IN MX 20 chewy.mc.utmck.edu. IN SOA 165.6.131.32. root.harley.mc.utmck.edu. ( 200284 19 10800 1800 604800 7200 ) ... $ORIGIN hosp.utmck.edu. ns-2 IN A 165.6.6.27 ... $ORIGIN mc.utmck.edu. harleyIN A 165.6.131.32 Thanks for your help, Steve ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Setting rr dns to only return one record?
Greetings all. Is it possible to set up BIND in such a way that if there are multiple A-records for a specific host, instead of returning all of them in response to a request and only changing the order with every second request, the server only returns one A-record, and varies that A-record with every second request? A little background: I am preparing to retire an aging load-balancing appliance which does dynamic load balancing based on various criteria. In any given response to a request for an A-record, only one IP address is returned, thus: ;; ANSWER SECTION: foo.test.com. 86400 IN A 192.168.1.10 With every other request, the IP varies. BIND's default behavior is to hand out both IPs, thus: ;; ANSWER SECTION: foo.test.com. 86400 IN A 192.168.1.10 foo.test.com. 86400 IN A 192.168.1.11 With every other request, the IPs' order changes. Certain browsers hitting our web application don't like having two A-records handed to them (I'm still in the process of figuring out why), and much prefer the first example above. We have two geographically dispersed locations, and too much traffic to realistically concentrate all of it to just one of the locations at present. Our load-balancer is near death, and I'm scrambling to replace it. I'm prepared to deal with the disaster-recovery scenario in which one of our locations becomes unavailable. My main objective is to replicate the behavior of our existing load balancer from the point of view of the end user, but ignore the dynamic aspect of it and use BIND to handle DNS. Any help or advice would be greatly appreciated. Best regards, Dustin Lovell America First Credit Union ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: can't see nameserver externally
On Dec 9 2008, Davenport, Steve M wrote: I noticed that one of our nameservers is no longer responding with the correct address externally. The server is ns-2.hosp.utmck.edu and is listed as a server in the registration record for utmck.edu. The address should be 165.6.6.27 but a dig/nslookup from an external site returns 165.6.144.1. We do not have 165.6.144.1 in any of the zone files, but this address is the external address of a broadband service manager in our network. Using dig/nslookup on the local network verifies that 165.6.144.1 is not in the zone files or cache of our nameservers. The name and address of our ns-2 resolve correctly internally. Can someone please tell me how to identify and correct this problem. It's probably coming from the glue at the GTLD nameservers: $ dig +norec +nostats +nocmd anything.utmck.edu @a.gtld-servers.net ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 346 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;anything.utmck.edu.IN A ;; AUTHORITY SECTION: utmck.edu. 172800 IN NS harley.mc.utmck.edu. utmck.edu. 172800 IN NS ns-2.hosp.utmck.edu. ;; ADDITIONAL SECTION: harley.mc.utmck.edu.172800 IN A 165.6.131.32 ns-2.hosp.utmck.edu.172800 IN A 165.6.144.1 ^ Try fixing your registration there. -- Chris Thompson Email: [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin <[EMAIL PROTECTED]> wrote:
> I test patch, add to bind95/Makefile
> .if (${ARCH} == "amd64")
> ARCH= x86_64
> .endif
Future versions of BIND9 will support amd64 in its configure script to
workaround the FreeBSD port for amd64.
Regarding the memory leak, I believe it's already solved in 9.5.1rc1
(even with threads and without atomic).
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Setting rr dns to only return one record?
At Tue, 09 Dec 2008 08:59:38 -0700, "Dustin Lovell" <[EMAIL PROTECTED]> wrote: > Greetings all. Is it possible to set up BIND in such a way that if > there are multiple A-records for a specific host, instead of > returning all of them in response to a request and only changing the > order with every second request, the server only returns one > A-record, and varies that A-record with every second request? It's not possible. And in case you're wondering, it breaks the notion of "resource record sets", so it's unlikely to be implemented in the future. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dnsperf and BIND memory consumption
Hi Jinmei,
Has anybody else tried this patch for you? I haven't had time to look into this
at all. If nobody has tried this yet, I'll get around to it when I can and let
you know the result.
-Vinny
> -Original Message-
> From: JINMEI Tatuya / 神明達哉 [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2008 1:06 AM
> To: Vinny Abello
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: dnsperf and BIND memory consumption
>
> At Tue, 2 Dec 2008 00:35:32 -0500,
> Vinny Abello <[EMAIL PROTECTED]> wrote:
>
> > For what it's worth, I just want to contribute that I can
> > confirm this behavior on my systems as well. On BIND 9.5.0-P2,
>
> From an off-list discussion, I found there was indeed memory leak in
> the code of 9.5.0-P2 (so I was wrong in suspecting it might be the
> FreeBSD thread library).
>
> Can you try the patched copied below to see whether it solves the
> problem?
>
> Note: this leak was already fixed in 9.5.1rc1:
>
> 2435. [bug] Fixed an ACL memory leak affecting win32.
>
> while the change description seems to indicate it's win32 specific,
> it can actually happen any build with threads and without atomic
> operations.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
> Index: acl.c
> ===
> RCS file: /proj/cvs/prod/bind9/lib/dns/acl.c,v
> retrieving revision 1.37.2.7
> diff -u -r1.37.2.7 acl.c
> --- acl.c 29 Apr 2008 01:04:14 - 1.37.2.7
> +++ acl.c 1 Dec 2008 03:17:36 -
> @@ -217,6 +217,7 @@
>
> /* Search radix. */
> result = isc_radix_search(acl->iptable->radix, &node, &pfx);
> + isc_refcount_destroy(&pfx.refcount);
>
> /* Found a match. */
> if (result == ISC_R_SUCCESS && node != NULL) {
> Index: iptable.c
> ===
> RCS file: /proj/cvs/prod/bind9/lib/dns/iptable.c,v
> retrieving revision 1.5.46.3
> diff -u -r1.5.46.3 iptable.c
> --- iptable.c 21 Jan 2008 21:02:24 - 1.5.46.3
> +++ iptable.c 1 Dec 2008 19:25:27 -
> @@ -74,6 +74,7 @@
> family = bitlen ? pfx.family : AF_INET;
>
> result = isc_radix_insert(tab->radix, &node, NULL, &pfx);
> + isc_refcount_destroy(&pfx.refcount);
>
> if (result != ISC_R_SUCCESS)
> return(result);
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Tue, 9 Dec 2008 15:26:25 -0500, Vinny Abello <[EMAIL PROTECTED]> wrote: > Has anybody else tried this patch for you? I haven't had time to > look into this at all. If nobody has tried this yet, I'll get around > to it when I can and let you know the result. No one else other than by myself. It worked perfectly for me, i.e., I could reproduce the problem and I could completely eliminate the leak with the patch. One thing I was not certain about in an off-list discussion that led to this patch was that the patch reportedly solved the leak only partially. I've been hoping to confirm that, but unfortunately I've not got any followup since then. So, basically, I believe the problem was solved, it would also help if you could confirm it. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dnsperf and BIND memory consumption
> -Original Message- > From: JINMEI Tatuya / 神明達哉 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 09, 2008 3:38 PM > To: Vinny Abello > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: dnsperf and BIND memory consumption > > At Tue, 9 Dec 2008 15:26:25 -0500, > Vinny Abello <[EMAIL PROTECTED]> wrote: > > > Has anybody else tried this patch for you? I haven't had time to > > look into this at all. If nobody has tried this yet, I'll get around > > to it when I can and let you know the result. > > No one else other than by myself. It worked perfectly for me, i.e., I > could reproduce the problem and I could completely eliminate the leak > with the patch. One thing I was not certain about in an off-list > discussion that led to this patch was that the patch reportedly solved > the leak only partially. I've been hoping to confirm that, but > unfortunately I've not got any followup since then. > > So, basically, I believe the problem was solved, it would also help if > you could confirm it. > > Thanks, > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. Jinmei, I'll try to confirm when I have some spare time and let you know. -Vinny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Round robin DNS and only one record?
Dustin Lovell wrote: Certain browsers hitting our web application don't like having two A-records handed to them (I'm still in the process of figuring out why), Yeah, you really need to dig into that further, since we have *hundreds* of multi-A-record names, and we've never run into any browser problems because of it. Misdiagnosis perhaps? Now, it _is_ true that some browsers take a noticeably -- and thus perhaps unacceptably -- long time to fail over from one address to another, when given a multi-A-record DNS response and the first address, or the first _n_ addresses, are unreachable. But if all of the addresses are reachable, I'm not aware of any browsers that have an issue with multi-A-record DNS responses _per_se_. They are extremely common. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: can't see nameserver externally
Davenport, Steve M wrote: Hello, I noticed that one of our nameservers is no longer responding with the correct address externally. The server is ns-2.hosp.utmck.edu and is listed as a server in the registration record for utmck.edu. The address should be 165.6.6.27 but a dig/nslookup from an external site returns 165.6.144.1. We do not have 165.6.144.1 in any of the zone files, but this address is the external address of a broadband service manager in our network. Using dig/nslookup on the local network verifies that 165.6.144.1 is not in the zone files or cache of our nameservers. The name and address of our ns-2 resolve correctly internally. Can someone please tell me how to identify and correct this problem. Have you checked the IP registered for the NS? ns-2.hosp.utmck.edu.172800 IN A 165.6.144.1 utmck.edu. 172800 IN NS harley.mc.utmck.edu. utmck.edu. 172800 IN NS ns-2.hosp.utmck.edu. ;; Received 123 bytes from 192.31.80.30#53(D.GTLD-SERVERS.NET) in 27 ms dig -tA ns-2.hosp.utmck.edu +trace ; <<>> DiG 9.2.4 <<>> -tA ns-2.hosp.utmck.edu +trace ;; global options: printcmd . 444765 IN NS F.ROOT-SERVERS.NET. . 444765 IN NS G.ROOT-SERVERS.NET. . 444765 IN NS H.ROOT-SERVERS.NET. . 444765 IN NS I.ROOT-SERVERS.NET. . 444765 IN NS J.ROOT-SERVERS.NET. . 444765 IN NS K.ROOT-SERVERS.NET. . 444765 IN NS L.ROOT-SERVERS.NET. . 444765 IN NS M.ROOT-SERVERS.NET. . 444765 IN NS A.ROOT-SERVERS.NET. . 444765 IN NS B.ROOT-SERVERS.NET. . 444765 IN NS C.ROOT-SERVERS.NET. . 444765 IN NS D.ROOT-SERVERS.NET. . 444765 IN NS E.ROOT-SERVERS.NET. ;; Received 500 bytes from 67.19.0.10#53(67.19.0.10) in 1 ms edu.172800 IN NS D.GTLD-SERVERS.NET. edu.172800 IN NS L.GTLD-SERVERS.NET. edu.172800 IN NS G.GTLD-SERVERS.NET. edu.172800 IN NS F.GTLD-SERVERS.NET. edu.172800 IN NS A.GTLD-SERVERS.NET. edu.172800 IN NS C.GTLD-SERVERS.NET. edu.172800 IN NS E.GTLD-SERVERS.NET. ;; Received 305 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 48 ms ns-2.hosp.utmck.edu.172800 IN A 165.6.144.1 utmck.edu. 172800 IN NS harley.mc.utmck.edu. utmck.edu. 172800 IN NS ns-2.hosp.utmck.edu. ;; Received 123 bytes from 192.31.80.30#53(D.GTLD-SERVERS.NET) in 27 ms ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
