Re: BIND 9.6.1-P3 using more resources?
On Friday, I wrote: We upgraded our main recursive nameservers (validating, via dlv.isc.org) from 9.6.1-P2 to 9.6.1-P3 a couple of days ago. CPU (and possibly memory) consumption have been quite a bit larger since then, and more worryingly, seems to be gradually increasing. I have looked for a co-incidental change in the query pattern that might explain this, without success so far. If anyone else has seen a similar effect as a result of upgrading, please let me know. I have found the cause, and it was not the upgrade to 9.6.1-P3 (so apologies for introducing any FUD about that) or a significant change to the query load. It was the result of adding -m record to the named argument list. I had put this in the startup script for when named was next restarted, and then half forgotten about it. I had in any case convinced myself that it was a trivial-cost option. Well, that turns out not to be the case ... (Using -m record was motivated by a unfreed-memory-at-shutdown abort that we observed with 9.6.1-P1 -- and not since -- and reported on bind9-bugs as RT #20675.) -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rndc stalls on any command -- maybe because 127.0.0.1 is not in routing table?
Hi all, The rndc tool, which is used for all BIND configuration (yast, /etc/init.d/named stop), appears to stall on any command. See [Listing 1] for output before it stalls (freezes not in the DNS zone sense) and [Listing 2] for afterwards. I used lsof to show the open files [Listing 3]. The last line doesn't appear to say it's a localhost source, and localhost doesn't seem to be in the routing tables [Listing 4]. Could this be the problem? If it is, could anyone consider adding a warning (or maybe even failing if an override option isn't set)? Thanks very much, Nicholas — ntung at ntung — https://ntung.com === Listing 1 -- output of command, process waits after last line === rndc -V stop create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get key decode base64 secret stop post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect === Listing 2 -- message after wait === rndc: connect failed: 127.0.0.1#953: timed out === Listing 3 -- open files when rndc is frozen === lsof -p $(ps -C rndc -o pid=) +L COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINKNODE NAME rndc19939 root cwdDIR 8,1812288 1088193 /etc rndc19939 root rtdDIR 8,18 409623 2 / rndc19939 root txtREG 8,1831800 1 1055141 /usr/sbin/rndc rndc19939 root memREG 8,18 346560 1 786938 /lib64/libm-2.10.1.so rndc19939 root memREG 8,1888640 1 786849 /lib64/libz.so.1.2.3 rndc19939 root memREG 8,1814872 1 786933 /lib64/libdl-2.10.1.so rndc19939 root memREG 8,18 1360392 1 7471871 /usr/lib64/libxml2.so.2.7.3 rndc19939 root memREG 8,18 1605840 1 7472655 /usr/lib64/libcrypto.so.0.9.8 rndc19939 root memREG 8,18 131260 1 786809 /lib64/libpthread-2.10.1.so rndc19939 root memREG 8,18 1408560 1 786838 /lib64/libc-2.10.1.so rndc19939 root memREG 8,18 354120 1 7471241 /usr/lib64/libisc.so.50.1.1 rndc19939 root memREG 8,18 1497256 1 7471310 /usr/lib64/libdns.so.53.0.0 rndc19939 root memREG 8,1843680 1 7475078 /usr/lib64/libbind9.so.50.0.3 rndc19939 root memREG 8,1835616 1 7471143 /usr/lib64/libisccc.so.50.0.0 rndc19939 root memREG 8,18 120168 1 7471234 /usr/lib64/libisccfg.so.50.0.0 rndc19939 root memREG 8,18 127680 1 786832 /lib64/ld-2.10.1.so rndc19939 root0u CHR 136,3 0t0 1 6 /dev/pts/3 rndc19939 root1u CHR 136,3 0t0 1 6 /dev/pts/3 rndc19939 root2u CHR 136,3 0t0 1 6 /dev/pts/3 rndc19939 root3r FIFO0,8 0t0 1 84973 pipe rndc19939 root4w FIFO0,8 0t0 1 84973 pipe rndc19939 root5u 0,90 1 679 anon_inode rndc19939 root7r REG0,30 1 10516 /proc/2283/status rndc19939 root 20u IPv4 84977 0t0 TCP c-98-207-60-37.hsd1.ca.comcast.net:55316-localhost:953 (SYN_SENT) === Listing 4 -- route configuration === ip route show 98.207.60.0/22 dev eth-inet proto kernel scope link src 98.207.60.37 169.254.0.0/16 dev eth0 scope link 192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.2.1 192.168.0.0/16 dev eth1 proto kernel scope link src 192.168.2.2 default via 98.207.60.1 dev eth-inet ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc stalls on any command -- maybe because 127.0.0.1 is not in routing table?
Is lo up? Is named actually listening on 127.0.0.1:953? Is there a firewall? On Sun, Jan 24, 2010 at 1:29 PM, Nicholas Tung nt...@ntung.com wrote: Hi all, The rndc tool, which is used for all BIND configuration (yast, /etc/init.d/named stop), appears to stall on any command. See [Listing 1] for output before it stalls (freezes not in the DNS zone sense) and [Listing 2] for afterwards. I used lsof to show the open files [Listing 3]. The last line doesn't appear to say it's a localhost source, and localhost doesn't seem to be in the routing tables [Listing 4]. Could this be the problem? If it is, could anyone consider adding a warning (or maybe even failing if an override option isn't set)? Thanks very much, Nicholas — ntung at ntung — https://ntung.com === Listing 1 -- output of command, process waits after last line === rndc -V stop create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get key decode base64 secret stop post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect === Listing 2 -- message after wait === rndc: connect failed: 127.0.0.1#953: timed out === Listing 3 -- open files when rndc is frozen === lsof -p $(ps -C rndc -o pid=) +L COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME rndc 19939 root cwd DIR 8,18 12288 108 8193 /etc rndc 19939 root rtd DIR 8,18 4096 23 2 / rndc 19939 root txt REG 8,18 31800 1 1055141 /usr/sbin/rndc rndc 19939 root mem REG 8,18 346560 1 786938 /lib64/libm-2.10.1.so rndc 19939 root mem REG 8,18 88640 1 786849 /lib64/libz.so.1.2.3 rndc 19939 root mem REG 8,18 14872 1 786933 /lib64/libdl-2.10.1.so rndc 19939 root mem REG 8,18 1360392 1 7471871 /usr/lib64/libxml2.so.2.7.3 rndc 19939 root mem REG 8,18 1605840 1 7472655 /usr/lib64/libcrypto.so.0.9.8 rndc 19939 root mem REG 8,18 131260 1 786809 /lib64/libpthread-2.10.1.so rndc 19939 root mem REG 8,18 1408560 1 786838 /lib64/libc-2.10.1.so rndc 19939 root mem REG 8,18 354120 1 7471241 /usr/lib64/libisc.so.50.1.1 rndc 19939 root mem REG 8,18 1497256 1 7471310 /usr/lib64/libdns.so.53.0.0 rndc 19939 root mem REG 8,18 43680 1 7475078 /usr/lib64/libbind9.so.50.0.3 rndc 19939 root mem REG 8,18 35616 1 7471143 /usr/lib64/libisccc.so.50.0.0 rndc 19939 root mem REG 8,18 120168 1 7471234 /usr/lib64/libisccfg.so.50.0.0 rndc 19939 root mem REG 8,18 127680 1 786832 /lib64/ld-2.10.1.so rndc 19939 root 0u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 1u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 2u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 3r FIFO 0,8 0t0 1 84973 pipe rndc 19939 root 4w FIFO 0,8 0t0 1 84973 pipe rndc 19939 root 5u 0,9 0 1 679 anon_inode rndc 19939 root 7r REG 0,3 0 1 10516 /proc/2283/status rndc 19939 root 20u IPv4 84977 0t0 TCP c-98-207-60-37.hsd1.ca.comcast.net:55316-localhost:953 (SYN_SENT) === Listing 4 -- route configuration === ip route show 98.207.60.0/22 dev eth-inet proto kernel scope link src 98.207.60.37 169.254.0.0/16 dev eth0 scope link 192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.2.1 192.168.0.0/16 dev eth1 proto kernel scope link src 192.168.2.2 default via 98.207.60.1 dev eth-inet ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- aRDy Music and Rick Dicaire present: http://www.ardynet.com http://www.ardynet.com:9000/ardymusic.ogg.m3u ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A question about PTR records
Hi, What is the best practice when using PTR in an ISP? is it dividing IP blocks (like; x.x.x.in-addr.arpa.) and therefore having more than one PTR zone file? or just use x.in-addr.arpa.and include everything inside that file? regards, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A question about PTR records
In message 139200.61342...@web110505.mail.gq1.yahoo.com, sasa sasa writes: Hi, What is the best practice when using PTR in an ISP? is it dividing IP block= s (like; x.x.x.in-addr.arpa.) and therefore having more than one PTR zo= ne file? or just use x.in-addr.arpa.and include everything inside that fi= le? regards, Whatever works best for you. If you are delegation parts of the in-addr.arpa namespace to others it is often easier to also delegate the namespace to yourself so that management is consistant. If you have RFC 2317 style delegations the parent zone, which contains the CNAMES, also needs to be transfered to ensure that reverse lookups continue to work on the subnet using that namespace. A smaller parent zone is useful in this case. Smaller zones also reduce the amount of data that needs to be transferred whenever a change happens. You can also mix and match. Note you can change schemes later if you want to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6.1-P3 using more resources?
In message prayer.1.3.2.1001241549090@hermes-2.csi.cam.ac.uk, Chris Thomp
son writes:
On Friday, I wrote:
We upgraded our main recursive nameservers (validating, via dlv.isc.org)
from 9.6.1-P2 to 9.6.1-P3 a couple of days ago. CPU (and possibly memory)
consumption have been quite a bit larger since then, and more worryingly,
seems to be gradually increasing.
I have looked for a co-incidental change in the query pattern that might
explain this, without success so far. If anyone else has seen a similar
effect as a result of upgrading, please let me know.
I have found the cause, and it was not the upgrade to 9.6.1-P3 (so apologies
for introducing any FUD about that) or a significant change to the query
load.
It was the result of adding -m record to the named argument list. I had
put this in the startup script for when named was next restarted, and
then half forgotten about it. I had in any case convinced myself that
it was a trivial-cost option. Well, that turns out not to be the case ...
It costs a ~16 bytes per memory allocation to perform the accounting
in a 32 bit build. ~24 bytes in a 64 bit build. Plus some computing
time.
struct debuglink {
ISC_LINK(debuglink_t) link;
const void *ptr[DEBUGLIST_COUNT];
unsigned intsize[DEBUGLIST_COUNT];
const char *file[DEBUGLIST_COUNT];
unsigned intline[DEBUGLIST_COUNT];
unsigned intcount;
};
With this we know where the memory that leaks was allocated and a
starting point to find the defect.
Mark
(Using -m record was motivated by a unfreed-memory-at-shutdown abort
that we observed with 9.6.1-P1 -- and not since -- and reported on
bind9-bugs as RT #20675.)
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc stalls on any command -- maybe because 127.0.0.1 is not in routing table?
Thanks very much! $(ifconfig lo up) fixed the first problem. I'm curious why the init script relies on this socket connection, and that it got a timeout instead of immediate failure because the interface wasn't up. [For anyone who has the same problem], it's necessary to run $(killall rpcbind named rndc) and $(/etc/init.d/named start) for named to start listening on the port. [further digression] I unintelligently deleted all of /etc/sysconfig/network/ifcfg* because yast2 lan was showing me a bunch of irrelevant old interfaces, but this deleted ifcfg-lo as well. Fortunately, I version controlled all of /etc/sysconfig :) and that's copied below if anyone needs it [1]. cheers, Nicholas — ntung at ntung — https://ntung.com [1] cat etc/sysconfig/network/ifcfg-lo # Loopback (lo) configuration IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 IPADDR_2=127.0.0.2/8 STARTMODE=onboot USERCONTROL=no FIREWALL=no On Sun, Jan 24, 2010 at 11:19 AM, Rick Dicaire kri...@gmail.com wrote: Is lo up? Is named actually listening on 127.0.0.1:953? Is there a firewall? On Sun, Jan 24, 2010 at 1:29 PM, Nicholas Tung nt...@ntung.com wrote: Hi all, The rndc tool, which is used for all BIND configuration (yast, /etc/init.d/named stop), appears to stall on any command. See [Listing 1] for output before it stalls (freezes not in the DNS zone sense) and [Listing 2] for afterwards. I used lsof to show the open files [Listing 3]. The last line doesn't appear to say it's a localhost source, and localhost doesn't seem to be in the routing tables [Listing 4]. Could this be the problem? If it is, could anyone consider adding a warning (or maybe even failing if an override option isn't set)? Thanks very much, Nicholas — ntung at ntung — https://ntung.com === Listing 1 -- output of command, process waits after last line === rndc -V stop create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get key decode base64 secret stop post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect === Listing 2 -- message after wait === rndc: connect failed: 127.0.0.1#953: timed out === Listing 3 -- open files when rndc is frozen === lsof -p $(ps -C rndc -o pid=) +L COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME rndc 19939 root cwd DIR 8,18 12288 108 8193 /etc rndc 19939 root rtd DIR 8,18 4096 23 2 / rndc 19939 root txt REG 8,18 31800 1 1055141 /usr/sbin/rndc rndc 19939 root mem REG 8,18 346560 1 786938 /lib64/libm-2.10.1.so rndc 19939 root mem REG 8,18 88640 1 786849 /lib64/libz.so.1.2.3 rndc 19939 root mem REG 8,18 14872 1 786933 /lib64/libdl-2.10.1.so rndc 19939 root mem REG 8,18 1360392 1 7471871 /usr/lib64/libxml2.so.2.7.3 rndc 19939 root mem REG 8,18 1605840 1 7472655 /usr/lib64/libcrypto.so.0.9.8 rndc 19939 root mem REG 8,18 131260 1 786809 /lib64/libpthread-2.10.1.so rndc 19939 root mem REG 8,18 1408560 1 786838 /lib64/libc-2.10.1.so rndc 19939 root mem REG 8,18 354120 1 7471241 /usr/lib64/libisc.so.50.1.1 rndc 19939 root mem REG 8,18 1497256 1 7471310 /usr/lib64/libdns.so.53.0.0 rndc 19939 root mem REG 8,18 43680 1 7475078 /usr/lib64/libbind9.so.50.0.3 rndc 19939 root mem REG 8,18 35616 1 7471143 /usr/lib64/libisccc.so.50.0.0 rndc 19939 root mem REG 8,18 120168 1 7471234 /usr/lib64/libisccfg.so.50.0.0 rndc 19939 root mem REG 8,18 127680 1 786832 /lib64/ld-2.10.1.so rndc 19939 root 0u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 1u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 2u CHR 136,3 0t0 1 6 /dev/pts/3 rndc 19939 root 3r FIFO 0,8 0t0 1 84973 pipe rndc 19939 root 4w FIFO 0,8 0t0 1 84973 pipe rndc 19939 root 5u 0,9 0 1 679 anon_inode rndc 19939 root 7r REG 0,3 0 1 10516 /proc/2283/status rndc 19939 root 20u IPv4 84977 0t0 TCP c-98-207-60-37.hsd1.ca.comcast.net:55316-localhost:953 (SYN_SENT) === Listing 4 -- route configuration === ip route show 98.207.60.0/22 dev eth-inet proto kernel scope link src 98.207.60.37 169.254.0.0/16 dev eth0 scope link 192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.2.1 192.168.0.0/16 dev eth1 proto kernel scope link src 192.168.2.2 default via 98.207.60.1 dev eth-inet ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- aRDy Music and Rick Dicaire present:
RE: A question about PTR records
Thanks Mark. -Original Message- From: bind-users-bounces+batpower83=yahoo.co...@lists.isc.org [mailto:bind-users-bounces+batpower83=yahoo.co...@lists.isc.org] On Behalf Of Mark Andrews Sent: Monday, January 25, 2010 2:11 AM To: sasa sasa Cc: bind-users@lists.isc.org Subject: Re: A question about PTR records In message 139200.61342...@web110505.mail.gq1.yahoo.com, sasa sasa writes: Hi, What is the best practice when using PTR in an ISP? is it dividing IP block= s (like; x.x.x.in-addr.arpa.) and therefore having more than one PTR zo= ne file? or just use x.in-addr.arpa.and include everything inside that fi= le? regards, Whatever works best for you. If you are delegation parts of the in-addr.arpa namespace to others it is often easier to also delegate the namespace to yourself so that management is consistant. If you have RFC 2317 style delegations the parent zone, which contains the CNAMES, also needs to be transfered to ensure that reverse lookups continue to work on the subnet using that namespace. A smaller parent zone is useful in this case. Smaller zones also reduce the amount of data that needs to be transferred whenever a change happens. You can also mix and match. Note you can change schemes later if you want to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
