Re: heavy named problems
31-May-2005 13:23:51.045 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.045 general: error: isc_mutex_init failed in new_adbfind() 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: isc_mutex_init failed in new_adbfind() I'm seeing this on both FreeBSD 5.4-p1 and -STABLE, either named will hang around the 100 - 250M memory mark with top output like ... last pid: 20483; load averages: 0.98, 0.67, 0.44 up 4+03:26:18 12:32:27 34 processes: 2 running, 32 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 237M Active, 150M Inact, 119M Wired, 24K Cache, 214M Buf, 1407M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 19847 bind 200 232M 228M kserel 1 61:57 98.97% 98.97% named As you can see plenty of memory free. Or if I drop down the datasize and cache size then I get the above crash. Any ideas anyone ? The only thing you should do with datasize is raise it. The option is there so that the process can get *more* than the default memory allocation. If you want to restict the amount of memory being used then max-cache-size is what should be set. Note for this to be effective it needs to trigger *before* named's memory usage hits the datasize limit. Lowering both datasize and max-cache-size is generally counter productive. True, but with none in place (I'd like it to use a gig or so if possible for the cache), then the system "freezes" and needs to be kill -9'ed and restarted, hence why I dropped the memory limits / put them in place in the first place. Ideally I'd like this machine to not crash at all since it's the primary cache. Have I run into some obscure bug ? Well FreeBSD defaults to a system wide maximum datasize of 512M (MAXDSIZ) and requires the kernel to be tuned to raise. options MAXDSIZ="(1024*1024*1024)" options DFLDSIZ="(1024*1024*1024)" Already got them in the kernel. Still got issues though. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: heavy named problems
> On 31/05/2005, at 3:08 PM, Mark Andrews wrote: > > > > > > >> 31-May-2005 13:23:51.045 general: error: /usr/src/lib/bind/ > >> dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > >> 31-May-2005 13:23:51.045 general: error: isc_mutex_init failed in > >> new_adbfind() > >> 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ > >> dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > >> 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ > >> dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > >> 31-May-2005 13:23:51.891 general: error: isc_mutex_init failed in > >> new_adbfind() > >> > >> I'm seeing this on both FreeBSD 5.4-p1 and -STABLE, either named will > >> hang around the 100 - 250M memory mark with top output like ... > >> > >> last pid: 20483; load averages: 0.98, 0.67, > >> 0.44 up 4+03:26:18 > >> 12:32:27 > >> 34 processes: 2 running, 32 sleeping > >> CPU states: % user, % nice, % system, % > >> interrupt, % idle > >> Mem: 237M Active, 150M Inact, 119M Wired, 24K Cache, 214M Buf, 1407M > >> Free > >> Swap: 4096M Total, 4096M Free > >> > >>PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU > >> COMMAND > >>19847 bind 200 232M 228M kserel 1 61:57 98.97% > >> 98.97% named > >> > >> As you can see plenty of memory free. > >> > >> > >> Or if I drop down the datasize and cache size then I get the above > >> crash. Any ideas anyone ? > >> > > > > The only thing you should do with datasize is raise it. > > The option is there so that the process can get *more* than > > the default memory allocation. > > > > If you want to restict the amount of memory being used then > > max-cache-size is what should be set. Note for this to be > > effective it needs to trigger *before* named's memory usage > > hits the datasize limit. > > > > Lowering both datasize and max-cache-size is generally > > counter productive. > > > >> > > True, but with none in place (I'd like it to use a gig or so if > possible for the cache), then the system "freezes" and needs to be > kill -9'ed and restarted, hence why I dropped the memory limits / put > them in place in the first place. Ideally I'd like this machine to > not crash at all since it's the primary cache. Have I run into some > obscure bug ? Well FreeBSD defaults to a system wide maximum datasize of 512M (MAXDSIZ) and requires the kernel to be tuned to raise. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: heavy named problems
On 31/05/2005, at 3:08 PM, Mark Andrews wrote: 31-May-2005 13:23:51.045 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.045 general: error: isc_mutex_init failed in new_adbfind() 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: isc_mutex_init failed in new_adbfind() I'm seeing this on both FreeBSD 5.4-p1 and -STABLE, either named will hang around the 100 - 250M memory mark with top output like ... last pid: 20483; load averages: 0.98, 0.67, 0.44 up 4+03:26:18 12:32:27 34 processes: 2 running, 32 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 237M Active, 150M Inact, 119M Wired, 24K Cache, 214M Buf, 1407M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 19847 bind 200 232M 228M kserel 1 61:57 98.97% 98.97% named As you can see plenty of memory free. Or if I drop down the datasize and cache size then I get the above crash. Any ideas anyone ? The only thing you should do with datasize is raise it. The option is there so that the process can get *more* than the default memory allocation. If you want to restict the amount of memory being used then max-cache-size is what should be set. Note for this to be effective it needs to trigger *before* named's memory usage hits the datasize limit. Lowering both datasize and max-cache-size is generally counter productive. True, but with none in place (I'd like it to use a gig or so if possible for the cache), then the system "freezes" and needs to be kill -9'ed and restarted, hence why I dropped the memory limits / put them in place in the first place. Ideally I'd like this machine to not crash at all since it's the primary cache. Have I run into some obscure bug ? On Fri, 12 Nov 2004, Michael Riexinger wrote: i have freebsd 5.3-release with the base bind 9.3 (chrooted). It allows recursive queries. After few hours running, the server answers to every query with SERVFAIL. Few minutes before, in the logs is this: named: isc_mutex_init failed in new_adbfind() After /etc/rc.d/named restart it's working fine for a couple of hours... What could cause this problem? Out of memory? Hitting memory limits? The code appears to chuck the return code if its nonzero, which is pesky. I suspect its ENOMEM, though. How big is the named process when it starts malfunctioning? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: heavy named problems
> 31-May-2005 13:23:51.045 general: error: /usr/src/lib/bind/ > dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > 31-May-2005 13:23:51.045 general: error: isc_mutex_init failed in > new_adbfind() > 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ > dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ > dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: > 31-May-2005 13:23:51.891 general: error: isc_mutex_init failed in > new_adbfind() > > I'm seeing this on both FreeBSD 5.4-p1 and -STABLE, either named will > hang around the 100 - 250M memory mark with top output like ... > > last pid: 20483; load averages: 0.98, 0.67, > 0.44 up 4+03:26:18 > 12:32:27 > 34 processes: 2 running, 32 sleeping > CPU states: % user, % nice, % system, % > interrupt, % idle > Mem: 237M Active, 150M Inact, 119M Wired, 24K Cache, 214M Buf, 1407M > Free > Swap: 4096M Total, 4096M Free > >PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU > COMMAND >19847 bind 200 232M 228M kserel 1 61:57 98.97% > 98.97% named > > As you can see plenty of memory free. > > > Or if I drop down the datasize and cache size then I get the above > crash. Any ideas anyone ? The only thing you should do with datasize is raise it. The option is there so that the process can get *more* than the default memory allocation. If you want to restict the amount of memory being used then max-cache-size is what should be set. Note for this to be effective it needs to trigger *before* named's memory usage hits the datasize limit. Lowering both datasize and max-cache-size is generally counter productive. > Cheers, > > Mark > > On 18/11/2004, at 1:09 PM, Doug White wrote: > > > On Fri, 12 Nov 2004, Michael Riexinger wrote: > > > > > >> i have freebsd 5.3-release with the base bind 9.3 (chrooted). It > >> allows > >> recursive queries. After few hours running, the server answers to > >> every > >> query with SERVFAIL. Few minutes before, in the logs is this: > >> > >> > >> named: isc_mutex_init failed in new_adbfind() > >> > >> After /etc/rc.d/named restart it's working fine for a couple of > >> hours... > >> What could cause this problem? > >> > > > > Out of memory? Hitting memory limits? > > > > The code appears to chuck the return code if its nonzero, which is > > pesky. > > I suspect its ENOMEM, though. > > > > > > How big is the named process when it starts malfunctioning? > > > > -- > > Doug White| FreeBSD: The Power to Serve > > [EMAIL PROTECTED] | www.FreeBSD.org > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable- > > [EMAIL PROTECTED]" > > > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: heavy named problems
31-May-2005 13:23:51.045 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.045 general: error: isc_mutex_init failed in new_adbfind() 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: /usr/src/lib/bind/ dns/../../../contrib/bind9/lib/dns/adb.c:1439: unexpected error: 31-May-2005 13:23:51.891 general: error: isc_mutex_init failed in new_adbfind() I'm seeing this on both FreeBSD 5.4-p1 and -STABLE, either named will hang around the 100 - 250M memory mark with top output like ... last pid: 20483; load averages: 0.98, 0.67, 0.44 up 4+03:26:18 12:32:27 34 processes: 2 running, 32 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 237M Active, 150M Inact, 119M Wired, 24K Cache, 214M Buf, 1407M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 19847 bind 200 232M 228M kserel 1 61:57 98.97% 98.97% named As you can see plenty of memory free. Or if I drop down the datasize and cache size then I get the above crash. Any ideas anyone ? Cheers, Mark On 18/11/2004, at 1:09 PM, Doug White wrote: On Fri, 12 Nov 2004, Michael Riexinger wrote: i have freebsd 5.3-release with the base bind 9.3 (chrooted). It allows recursive queries. After few hours running, the server answers to every query with SERVFAIL. Few minutes before, in the logs is this: named: isc_mutex_init failed in new_adbfind() After /etc/rc.d/named restart it's working fine for a couple of hours... What could cause this problem? Out of memory? Hitting memory limits? The code appears to chuck the return code if its nonzero, which is pesky. I suspect its ENOMEM, though. How big is the named process when it starts malfunctioning? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: heavy named problems
On Fri, 12 Nov 2004, Michael Riexinger wrote: > i have freebsd 5.3-release with the base bind 9.3 (chrooted). It allows > recursive queries. After few hours running, the server answers to every > query with SERVFAIL. Few minutes before, in the logs is this: > > > named: isc_mutex_init failed in new_adbfind() > > After /etc/rc.d/named restart it's working fine for a couple of hours... > What could cause this problem? Out of memory? Hitting memory limits? The code appears to chuck the return code if its nonzero, which is pesky. I suspect its ENOMEM, though. How big is the named process when it starts malfunctioning? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"