Re: Bind vs flood
On 27.02.2014 09:59, Dmitry Rybin wrote: Bind answers with Server failure. On high load (4 qps) all normal client can get Servfail on good query. Or query can execute more 2-3 second. I have an a mistake, 4'000 QPS. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind vs flood
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com
vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com
and many others.
Bind answers with Server failure. On high load (4 qps) all normal
client can get Servfail on good query. Or query can execute more 2-3 second.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Max number of views and performance.
24.08.2011 08:04, sky shade пишет: Hello I like to know if bind 9.8 have a limit of view? There is any number or I can create something like 1 million views without problems? There is any performance implication in use to many views? I use about 120 views. It accure 1,8gb of RAM in Idle. You must limit recursive cache to 32-64MB per view, and forward all recursive queries to another DNS server (I use powerdns-recurser at 127.0.0.2) for best perfomance. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: maximum number of FD events (64) received
28.09.2010 10:46, JINMEI Tatuya / 神明達哉 пишет: These logs are not (directly) related to file descriptors. They mean epoll returned more socket events than the implementation normally expects (which is 64). This is not necessarily an error because the remaining events will be returned with the next call to epoll_wait(). However, the event loop should generally runs pretty quickly, so it's still an unexpected situation. You may want to check overall stability of the server, e.g., in terms of the ratio of server failures (SERVFAIL) that your server returns to the clients, cache memory footprint, cache hit ratio, number of query drops (if any), etc. If these are okay and you only see the log messages occasionally, you can probably ignore them. Otherwise, if you use multiple threads on a multi-core machine and you set max-cache-size to some finite value, you may be hit by a recently found bug in the cache memory management, which can make a caching server very busy. (but it's a wild guess: I've personally never seen this bug trigger the log message in question). This bug will be fixed in 9.7.2. A have same error after upgrade from 9.7.0-P1 to 9.7.2-P2: Dec 9 11:40:03 thunderball named[13574]: 09-Dec-2010 11:40:03.719 general: info: sockmgr 0x101856f70: maximum number of FD events (64) received bind-9.7.2-P3, FreeBSD 8. vanilla src: make with: $ STD_CDEFINES='-DFD_SETSIZE=16384' ./configure --enable-threads --enable-largefile --enable-atomic --with-libxml2=yes $ STD_CDEFINES='-DFD_SETSIZE=16384' make === Decision: Add to configure make STD_CDEFINES='-DISC_SOCKET_MAXEVENTS=256' -- Рыбин Дмитрий Эксперт по аварийному восстановлению сервисов Отдел систем ШПД Департамент ИТ- инфраструктуры Группа компаний Вымпелком Tel: +7(495) 7871000 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: limiting number of recursion/queries per IP address
This is not good idea to use statefull firewall on heavy loaded DNS server. firewall becomes low place in the system. As workaround you can use dns_flood_detector + simple script to insert and remove IP's from firewall blocking table or chain. 27.10.2010 23:26, Sebastian Tymków пишет: In FreeBSD you can use pf to limit connections using tables and setting up rate limit. http://forums.freebsd.org/showthread.php?t=1727 Best regards, Shamrock On Tue, Oct 26, 2010 at 9:29 PM, Kebba Foon kebba.f...@qcell.gm mailto:kebba.f...@qcell.gm wrote: On Tue, 2010-10-26 at 15:22 -0400, Todd Snyder wrote: What version of bind, on what OS? I use Debian 5.0 with bind 9.6-ESV-R1 but also i thought that the OS might have some security holes so i try FreeBSD 8.1 with BIND 9.7.1 but still have ihave the same problems. here may be some things you can do with iptables to limit connections http://www.debian-administration.org/articles/187 i will just look into these but it done thing iptables will be the ideal solution. I don't recall seeing anything native to BIND that would allow for limits per src. t. -Original Message- From: bind-users-bounces+tsnyder=rim.com http://rim.com@lists.isc.org http://lists.isc.org [mailto:bind-users-bounces+tsnyder mailto:bind-users-bounces%2Btsnyder=rim.com http://rim.com@lists.isc.org http://lists.isc.org] On Behalf Of Kebba Foon Sent: Tuesday, October 26, 2010 2:27 PM To: bind-users@lists.isc.org mailto:bind-users@lists.isc.org Subject: limiting number of recursion/queries per IP address Dear List, Is is possible to limit the number of recursion/queries per IP address. there is some kind of virus thats bombarding my dns servers with a lot of queries, i realize that when ever the total number of recursion clients reach 1000 dns resolution stop working. i have increase the recursive-clients to 1 but still these those not help. and also i have increase the number of max open files on my OS which at one point was complaining about too many open files. can someone please direct me to how best to solve this problem its some kind of DDOS. Thanks Kebba ___ bind-users mailing list bind-users@lists.isc.org mailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org mailto: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 -- Рыбин Дмитрий Эксперт по аварийному восстановлению сервисов Отдел систем ШПД Департамент ИТ- инфраструктуры Группа компаний Вымпелком Tel: +7(495) 7871000 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursing stop at about 1000 clients
I've test next configuration, which improve recursion performance of
isc-bind frontend.
bind listen on only on external interface and forward all recursive
queries to 127.0.0.1
=== named.conf ===
listen-on { 1.1.1.1; };
forward only;
forwarders {
127.0.0.1;
};
=== named.conf ===
Test without forward:
1 q - 23.362 s
rndc status 280/0/500
LA: 2
Test with
1 q - 24.162 s
rndc status 53/0/500
LA: 1.33
powerdns-recursor 3.2 listen on loopback interface.
sockstat:
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
pdns_recursor pdns_recur64672 4 udp4 127.0.0.1:53 *:*
pdns_recursor pdns_recur64672 5 tcp4 127.0.0.1:53 *:*
bind named 1004 25 tcp41.1.1.1:53 *:*
bind named 1004 513 udp4 1.1.1.1:53 *:*
21.07.2010 03:31, Robert Mibus пишет:
Check that your underlying OS/environment is not limiting you - eg., you
may be getting limited to 1024 file descriptors via ulimit.
Robert.
On 15/07/2010, at 7:48 PM, Kebba Foon wrote:
i did i set my recursive-clients to 1 but it does not help.
On Thu, 2010-07-15 at 20:21 +1000, Noel Butler wrote:
UDP
___
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Robert Mibus rmi...@internode.com.au mailto:rmi...@internode.com.au
Systems Operations, Internode
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Рыбин Дмитрий
Эксперт по аварийному восстановлению сервисов
Отдел систем ШПД
Департамент ИТ- инфраструктуры
Группа компаний Вымпелком
Tel: +7(495) 7871000
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Load Balancer for DNS
05.04.2010 10:06, sasa sasa пишет: Hello everyone, Any one used any load balancer for DNSs? any recommendation? it's 2 caching-only DNSs, and I'd like to make a load balance between them using software. Simple - Linux, FreeBSD firewall as balancer :) (30k qps) Can give you example configuration. Advanced - Cisco ACE 4710. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
change ONLY one record in zone
Hello bind gurus! I need to change only one record in zone (not deligated to my server, can't transfer it too) RECORD.DOMAIN.NET IN A 192.168.1.1 to RECORD.DOMAIN.NET IN CNAME RECORD.DOMAIN.ORG Only one record! Is this possible via bind? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: change ONLY one record in zone
Matus UHLAR - fantomas wrote: I need to change only one record in zone (not deligated to my server, can't transfer it too) RECORD.DOMAIN.NET IN A 192.168.1.1 to RECORD.DOMAIN.NET IN CNAME RECORD.DOMAIN.ORG Only one record! Is this possible via bind? Not if ht domain is not yours. You must ask the person who maintains domain.net. I know it. But the question in other. Is this possible via bind? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: isc_socket_create: fcntl/reserved: Too many open files
Hi! RTFM :) /etc/security/limits.conf binduser softnofile 32384 binduser hardnofile 32384 change binduser - to you real BIND user. john wrote: Hi, I'm seeing this quite frequently in syslog from bind: Dec 7 11:00:00 ext named[26731]: isc_socket_create: fcntl/reserved: Too many open files Dec 7 11:00:00 ext named[26731]: isc_socket_create: fcntl/reserved: Too many open files Googling found someone asked before on here in February and was advised to upgrade to 9.3.6, however I'm using 9.5.1-P3 (debian release). Any ideas how to fix this? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
Give me parabellum :) This is not answer. I wont to disable Refused answers for not allowed client in recursion. Peter Andreev wrote: Search in arm by keyword blackhole will save father of russian democracy :-) 2009/12/3 Dmitry Rybin kirg...@corbina.net mailto:kirg...@corbina.net Barry Margolin wrote: In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org mailto:mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@corbina.net mailto:kirg...@corbina.net wrote: Hello! I can't find in docs how disable answer (Refused), if recursion for IP is not allowed? What do you expect it to do instead? Not respond at all? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disable Refused answer
Hello! I can't find in docs how disable answer (Refused), if recursion for IP is not allowed? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
I found answer for my feature request - simple C proxer: http://www.wolfermann.org/dnsproxy.html It can forward queries to auth or recursion server. Based on client IPs. FreeBSD port /usr/ports/dns/dnsproxy/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: loading zone: creating database: out of memory
ulimit? 万善义 wrote: CentOS release 5.4 (Final) + BIND 9.6.1-P1 Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8G Memory Load 500,000 domains, the loading process, the following error: loading zone: creating database: out of memory ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
Kevin Darcy wrote: Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( ___ So, you don't cache locally, you forward to another daemon that (in the best case) answers from *its* cache. How have you improved performance by changing nothing else and adding a network hop? recursion possibilities of bind is very pity in compare with powerdns-recursor, unbound so on. It allocate a lot of memory and make high CPU usage. Sometimes unable change authoritative and recursive IPs. The decision is: Authoritative q: bind answer it Recursive: pass from bind ACL and proxy all recursive queries to special recursion daemon. It'll be very useful option. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
Matus UHLAR - fantomas wrote: Bind answer authoritative for all clients, and forward (if allowed) recursive queries to recursive server. why shouldn't it cache those responses? Bind cache is slow. It allocate a lot of memory and make high CPU usage. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Feature request - disable internal recursion cache
Hello everybody! I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
Niall O'Reilly wrote: I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( I don't see the point. If you need some code, other than BIND named, to handle recursive queries from your clients, why not just have that code listening on the addresses configured in the stub resolver on each of the client systems? I'll explain, why. Same Server is authoritative for internet/intranet and recursive for intranet and one large AS. Sometimes Auth/Rec server IP cannot be spited into different IP's. Bind answer authoritative for all clients, and forward (if allowed) recursive queries to recursive server. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: attach-cache sample
JINMEI Tatuya / 神明達哉 wrote:
Have anybody test option attach-cache? There is no documentation about
it. :(
Have you read the ARM? It may not be sufficient (while I personally
believe it's quite extensive), but at least there *is* documentation.
OK, Please explain what configuration parameter mismatch:
view world {
zone 0.0.127.IN-ADDR.ARPA {
type master;
file localhost.rev;
};
[other zones]
};
view view0 {
attach-cache world;
[zones]
};
named.log
Aug 14 10:14:24 kananga named-7[37361]: 14-Aug-2009 10:14:24.625
general: error: views world and view0 can't share the cache due to
configuration parameter mismatch
There is no specific parameter in views configuration as:
check-names, cleaning-interval, dnssec-accept-expired,
dnssec-validation, max-cache-ttl, max-ncache-ttl, max-cache-size, and
zero-no-soa-ttl. Only identical zones with different zone files.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
attach-cache sample
Hello! Have anybody test option attach-cache? There is no documentation about it. :( I add attach-cache world (world - global view) and rndc reload failure: Aug 13 16:59:49 kananga named-7[37361]: 13-Aug-2009 16:59:49.262 general: error: views view0 and view1 can't share the cache due to configuration parameter mismatch Aug 13 16:59:49 kananga named-7[37361]: 13-Aug-2009 16:59:49.268 general: error: reloading configuration failed: failure version: 9.7.0a2 CPUs found: 8 worker threads: 8 number of zones: 1267 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 313/1900/2000 tcp clients: 0/100 server is up and running ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My 9.5.1-P3 exit suddenly.
ulimit -a ? Looks like as max open file descriptor limit exceeded. On FreeBSD/Linux boxes I use MONIT (http://mmonit.com/monit/) то check and restart bind. BBB Kee wrote: Hi, We have a intel solaris 9 and bind9.5.1-P3 inside it. The named suddenly stopped at this morning. Here is it left: ... 11-Aug-2009 06:09:14.466 general: error: failed to start watching FD (512): invalid file 11-Aug-2009 06:09:14.467 general: error: failed to start watching FD (512): invalid file 11-Aug-2009 06:09:14.467 general: error: failed to start watching FD (512): invalid file 11-Aug-2009 06:09:14.467 general: error: failed to start watching FD (512): invalid file 11-Aug-2009 06:09:14.467 general: critical: socket.c:2413: INSIST(!sock-pending_recv) failed 11-Aug-2009 06:09:14.468 general: critical: exiting (due to assertion failure) What is the problem? Can I fix it? ___ 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
Re: clearing local caches
Hello. powerdns-recursor - the best. :)) Over 20k req/sec - feel good. As variant try to use small TTL like: bind: max-ncache-ttl 1; max-cache-ttl 1; powerdns-recursor cache-ttl=1 default-ttl=1 Scott Haneda wrote: Hello, this may not entirely be related to BIND/named, though I believe it is. I am working on a set of benchmarks to test the resolving speed of different recursive DNS providers. My plan is call an http resource, and see how long it takes to resolve that host, as well as all embedded hosts and redirects within the html. After the initial test, I will want to call the same resource, with a different resolver. What is the most reliable way to clear any caches I would have picked up from the first request? I suspect I should call it 2x, so the remote resolver can cache the request, and provide those results as well? Currently, I was planing on using a browser, and timing the page request from start to stop with javascript. I am not entirely in love with this idea for obvious reasons. Can anyone suggest a better method? I could grep out the url's from an ad heavy url, and curl each of those, making a cumulative time result. However, I would like to just get DNS response times. Perhaps take the list of hosts and feed them to a iterative script calling dig, and fish out the response time? This does add the problem of redirects of course would not be followed, so I would have to pre-fetch all my urls and follow them to get my testing list. Thanks for any suggestions. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL debugging
JINMEI Tatuya / 神明達哉 wrote: At Wed, 24 Jun 2009 10:13:51 +0400, Dmitry Rybin kirg...@corbina.net wrote: new experimental feature just for that purpose: Is this feature going to be back ported to 9.4 and 9.5 releases as well? For 9.5, yes. For 9.4, not according to the current plan. named[87071]: 22-Jun-2009 13:18:23.256 query-errors: debug 2: fetch completed at resolver.c:6569 for static.cache.l.google.com/A in 0.041364: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Which version of BIND9 is this? To match the line number we need the exact version number. FreeBSD 7.2-STABLE, bind from ports bind96-9.6.1 Okay, then the above log strongly suggests that the cache is full in some unusual way and even recently fetched RR (which is in this case NS for google.com) has been purged before it's actually used. There have been bugs that could cause this symptom, but all known problems should have been solved in 9.6.1. So, I have no specific idea about how exactly that happened. Can you provide the following information? - your complete named.conf - if you enable statistics-channel, its output when you see this trouble - the result of rndc dump when you see this trouble (note: rndc dump purges stale cache entries as a side effect and may hide the cause. It will still help investigate the problem) If you think it's sensitive please contact me offlist. I'll send it offlist, but results may be interested to all other. Bind 9.7 works better, and I didn't see this error. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL debugging
JINMEI Tatuya / 神明達哉 wrote: At Mon, 22 Jun 2009 13:30:42 +0400, Dmitry Rybin kirg...@corbina.net wrote: Please try 9.6.1b1, which we expect to be released next week. It has a new experimental feature just for that purpose: Is this feature going to be back ported to 9.4 and 9.5 releases as well? For 9.5, yes. For 9.4, not according to the current plan. named[87071]: 22-Jun-2009 13:18:23.256 query-errors: debug 2: fetch completed at resolver.c:6569 for static.cache.l.google.com/A in 0.041364: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Which version of BIND9 is this? To match the line number we need the exact version number. --- JINMEI, Tatuya Internet Systems Consortium, Inc. FreeBSD 7.2-STABLE, bind from ports bind96-9.6.1 version: 9.6.1 CPUs found: 8 worker threads: 6 number of zones: 1258 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 3 query logging is OFF recursive clients: 162/1900/2000 tcp clients: 0/100 server is up and running It one of 3 other dns servers, and after update to 9.6.1 from 9.6.0 I have an error, then allocated by the bind memory grows more 2,5-3 gb. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL debugging
JINMEI Tatuya / 神明達哉 wrote: At Fri, 13 Mar 2009 17:31:37 -0400, R Dicaire kri...@gmail.com wrote: Please try 9.6.1b1, which we expect to be released next week. It has a new experimental feature just for that purpose: Is this feature going to be back ported to 9.4 and 9.5 releases as well? For 9.5, yes. For 9.4, not according to the current plan. Note also that this is a new experimental feature. So far, we've only included a new feature in a .0 release, so this logging feature would only appear in 9.7.0. We're now trying to seek an intermediate path, considering the tradeoff between the plus of providing useful features for older versions and the risk of introducing instability to maintenance release. So, we may even remove this feature from the final release of 9.6.1 if we find significant regression with it through the beta cycle. On the other hand, we may include it to the next version of 9.4 if we find it very useful and can be sure that it does no harm. --- JINMEI, Tatuya Internet Systems Consortium, Inc. Hello! what does it mean: named[87071]: 22-Jun-2009 13:18:23.256 query-errors: debug 2: fetch completed at resolver.c:6569 for static.cache.l.google.com/A in 0.041364: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] named[87071]: 22-Jun-2009 13:18:23.073 query-errors: debug 2: fetch completed at resolver.c:6569 for adservices.l.google.com/A in 0.461466: SERVFAIL/success [domain:l.google.com,referral:3,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] amed[87071]: 22-Jun-2009 13:18:22.401 query-errors: debug 2: fetch completed at resolver.c:6569 for googlehosted.l.google.com/A in 0.007844: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] -- Рыбин Дмитрий Управление магистральной сети Отдел Информационных Систем Руководитель группы АВР 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: Failover
The Best - use carp (VRRP) protocol for it or nginx proxy server. Or you can use dynamic update for zone: ping -c 5 your.host || nsupdate ... Mohammed Ejaz wrote: Hi all, Can it be possible through the bind, www records should work as failover, I mean during the primary record unavailable and then it should go for next www only, Pls. note that I don’t want let they work as round robin function. 1. Primary www record pointing 1.2.3.4 as long as it is available it should read from the same IP, 2. Secondary www record pointing 4.3.2.1 it should act only incase of primary is down. Ejaz ___ 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
Re: Disable cache in bind 9.6
Matus UHLAR - fantomas wrote: and let me know if it mitigates the problem? On 29.01.09 22:50, Dmitry Rybin wrote: Oh, great work. I'll try tomorrow. Named with JINMEI Tatuy patch: max-cache-size 800M; Morning Statistic version: 9.6.0-P1 CPUs found: 8 worker threads: 8 number of zones: 1040 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 167/4900/5000 tcp clients: 0/100 server is up and running Started at Feb 3 00:51 (Now Feb 4 11:15:37) MSK Startup mem: 890M Cur. memory usage: 2534M System limit: 16G ++ Incoming Requests ++ 112510181 QUERY 550 IQUERY 42 STATUS 1043 RESERVED3 101299 NOTIFY 101 UPDATE 14 RESERVED11 ++ Incoming Queries ++ 1929 RESERVED0 75241540 A 2105214 NS 100 CNAME 276292 SOA 2490 WKS 26826476 PTR 2 HINFO 4690581 MX 236619 TXT 24 X25 2003829 17 LOC 713837 SRV 46397 NAPTR 58 A6 1022 SPF 4 IXFR 5 AXFR 317561 ANY 23 Others ++ Outgoing Queries ++ Yes, I try it. But I can't set ttl to 0. It didn't work. Recursive query fails, and authoritative query back to clients with ttl 0 :( Yes, that is what Setting TTL to 0 means. ~50 views, can't you really lower the views count? It's impossible, :-( over 500'000 client use bind and we must use views to split load on another services. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
JINMEI Tatuya / 神明達哉 wrote: At Wed, 04 Feb 2009 11:23:19 +0300, Dmitry Rybin kirg...@corbina.net wrote: Named with JINMEI Tatuy patch: max-cache-size 800M; It's way too much, if this applies to all of the 50 views. With you patch? Total memory on server 12Gb. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
Matus UHLAR - fantomas wrote: On 04.02.09 11:23, Dmitry Rybin wrote: It's impossible, :-( over 500'000 client use bind and we must use views to split load on another services. Named with JINMEI Tatuy patch: max-cache-size 800M; It's way too much, if this applies to all of the 50 views. Oh! I decrease memory to 16Mb. Pardon? Split load? Do you use views to point different clients to different server to lower load on them? If so, you better should use DNS load balancing or some kind of HW/SW load balancer For first time was DNS load balancing. And after grow clients base we can use only current scheme. We think about it, but only bind with current configuration approach to us. Another variant - powerdns-recursor with LUA scripting. (in testing) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
В Пнд, 26/01/2009 в 16:16 -0800, JINMEI Tatuya / 神明達哉 пишет: http://www.jinmei.org/patch/bind9-lrucache.diff (should be cleanly applicable to 9.6). and let me know if it mitigates the problem? Oh, great work. I'll try tomorrow. Other recommendations: - I previously suggested using a separate cache-only view and forward all recursive queries to that view. Have you tried that? If you have, didn't it work as I hoped? Yes, I try it. But I can't set ttl to 0. It didn't work. Recursive query fails, and authoritative query back to clients with ttl 0 :( I increase memory on servers 2x QUAD CORE XEON up to 12Gb. PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 38634 bind11 40 3003M 2952M RUN2 159:28 46.44% named ~50 views, max-cache-size for most views 64M; bind uptime (after kernel: pid 667 (named), uid 53: exited on signal 11) - 2 days and 6 hours. built with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--d isable-openssl-version-check' '--without-openssl' '--with-libxml2=/usr/local' '--without-idn' '--enable-largefile' '--enable-threads' '--prefix=/usr/local' ' --mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd7.1' 'build_alias=x86_64-portbld-freebsd7.1' 'CC=cc' 'CFLAGS=-O2 -fno-st rict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/lib:/usr/local/lib' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe' rndc status: version: 9.6.0-P1 CPUs found: 8 worker threads: 8 On another server in same configuration bind works 2 days and die without core kernel: pid 682 (named), uid 53: exited on signal 11 Max memory per process - 12GB. May be FreeBSD x64 can't work more then X Gb per process? # cat /boot/loader.conf kern.maxdsiz=17179869184 # 16gb kern.dfldsiz=17179869184 # 16gb kern.maxssiz=134217728# 128MB - BIND 9.7 will have a new option attach-cache exactly for such an extraordinary operational environment as yours: it allows multiple views to share a single cache to save memory. I'll try to test 9.7 on one of the heavy load servers and post results to you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
Matus UHLAR - fantomas wrote: This is _NOT_ a problem of BIND. This is a problem of its admin who can't read the docs and set up max-cache-size, which does exactly what is needed in this case. Hmm... And why bind allocate all system memory, if max-cache-size 16M? And views... 50 views. 16*50=800M. Only 800M, this is not 3..4GB of system memory. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disable cache in bind 9.6
Hello! How to disable cache in bind-9.6? ttl=0 - bad idea. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
Matus UHLAR - fantomas wrote: On 20.01.09 12:49, Dmitry Rybin wrote: How to disable cache in bind-9.6? ttl=0 - bad idea. if you know that setting TTL to 0 is a bad idea, why do yuo think that disabling a cache in BIND is not a bad idea? Because under high load cache grows to maximum system size and stop responding to queues. This is known problem. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what versions of BIND and operating systems?
FreeBSD 7.1 i386, AMD64 - bind 9.5.1rc, 9.6.0rc works good. On Fri, 2008-12-19 at 12:39 -0600, Jeremy C. Reed wrote: Hi, I am working on BIND documentation and want to make sure the lists of operating systems used successfully with BIND are accurate. If you are willing, please email me off-list by December 23, what BIND and operating system versions you are successfully building and running BIND on. If you are not using vanilla BIND, please also let me know. Thanks! Currently the README from 9.5.x and upcoming 9.6.0 has: We have recent reports from the user community that a supported version of BIND will build and run on the following systems: AIX 4.3, 5L CentOS 4, 4.5, 5 Darwin 9.0.0d1/ARM Debian 4 Fedora Core 5, 7 FreeBSD 6.1 HP-UX 11.23 PA MacOS X 10.4, 10.5 Red Hat Enterprise Linux 4, 5 SCO OpenServer 5.0.6 Slackware 9, 10 SuSE 9, 10 And the README from 9.3.x and 9.4.x has: Additionally, we have unverified reports of success building previous versions of BIND 9 from users of the following systems: AIX 5L SuSE Linux 7.0 Slackware Linux 7.x, 8.0 Red Hat Linux 7.1 Debian GNU/Linux 2.2 and 3.0 Mandrake 8.1 OpenBSD 2.6, 2.8, 2.9, 3.1, 3.6, 3.8 UnixWare 7.1.1 HP-UX 10.20 BSD/OS 4.2 Mac OS X 10.1, 10.3.8 Jeremy C. Reed ISC Sales Support Engineer ___ 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
Re: dnsperf and BIND memory consumption
JINMEI Tatuya / 神明達哉 wrote: At Mon, 15 Dec 2008 09:53:23 +0300, Dmitry Rybin rybi...@post.ru wrote: Thank's to JINMEI Tatuya for support. I have over 40 views, defined in named.conf, max-memory for cache - 32Mb. Named daemon allocate over 2 Gb per 24 hours of work. Each view has a separate cache DB. So if each of these 40 views really needs to cache a certain amount of data, a footprint of 2GB is not a surprising situation, even with a 32MB of max-cache-size for each view. OK. I Just limit max-cache-size 16MB. 16MB * 50 views = over 800 MB of memory. How much total memory bind can accrue? -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
Thank's to JINMEI Tatuya for support.
I have over 40 views, defined in named.conf, max-memory for cache -
32Mb. Named daemon allocate over 2 Gb per 24 hours of work.
Have you any ideas how to limit memory usage?
Dmitry Rybin wrote:
max-cache-size 64M;
# /usr/bin/limits -v 1200M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
Over 10 minutes of work and core dumped:
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x0056645a in isc_mem_createx2 (init_max_size=0, target_size=0,
memalloc=0x564400 default_memalloc, memfree=0x563320
default_memfree, arg=0x0,
ctxp=0xcb29b978, flags=Variable flags is not available.
) at mem.c:790
#4 0x00566730 in isc_mem_create (init_max_size=Variable
init_max_size is not available.
) at mem.c:859
#5 0x004d83ae in dns_resolver_create (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=Variable socketmgr is not available.
) at resolver.c:6514
#6 0x004ee860 in dns_view_createresolver (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=0x8082b000, timermgr=0x80829000, options=0,
dispatchmgr=0x8083c000,
dispatchv4=0x864c9000, dispatchv6=0x864c9800) at view.c:580
#7 0x0041bba2 in configure_view (view=0xca46e800,
config=0x80abb4c0,
vconfig=0x8085ada8, mctx=0x8080d140, actx=0x7eff8860,
need_hints=isc_boolean_true)
at server.c:1290
#8 0x00420f42 in load_configuration (filename=Variable
filename is not available.
) at server.c:3285
#9 0x00422095 in loadconfig (server=0x8082f000) at server.c:4121
#10 0x00422426 in reload (server=0x8082f000) at server.c:4141
#11 0x004225c2 in ns_server_reloadcommand (server=0x8082f000,
args=Variable args is not available.
) at server.c:4334
#12 0x00407682 in ns_control_docommand (message=Variable
message is not available.
) at control.c:102
#13 0x0040a8b7 in control_recvmessage (task=0x80839000,
event=Variable event is not available.
) at controlconf.c:456
#14 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#15 0x005868a7 in thread_start ()
#16 0x in ?? ()
Cannot access memory at address 0x7eff9000
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin kirg...@corbina.net wrote:
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin kirg...@corbina.net 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).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M and
setting 'limits -v' to 512m).
3. Then the named process will eventually abort itself with a core dump
due to malloc failure. Please show us the stack trace at that point.
Hopefully it will reveal the malloc call that keeps consuming memory.
In fact, I myself successfully identified one leak in 9.5.0-P2 with
FreeBSD port this way.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
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
Re: dnsperf and BIND memory consumption
Thank's to JINMEI Tatuya for support.
I have over 40 views, defined in named.conf, max-memory for cache -
32Mb. Named daemon allocate over 2 Gb per 24 hours of work.
Have you any ideas how to limit memory usage?
Dmitry Rybin wrote:
max-cache-size 64M;
# /usr/bin/limits -v 1200M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
Over 10 minutes of work and core dumped:
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x0056645a in isc_mem_createx2 (init_max_size=0, target_size=0,
memalloc=0x564400 default_memalloc, memfree=0x563320
default_memfree, arg=0x0,
ctxp=0xcb29b978, flags=Variable flags is not available.
) at mem.c:790
#4 0x00566730 in isc_mem_create (init_max_size=Variable
init_max_size is not available.
) at mem.c:859
#5 0x004d83ae in dns_resolver_create (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=Variable socketmgr is not available.
) at resolver.c:6514
#6 0x004ee860 in dns_view_createresolver (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=0x8082b000, timermgr=0x80829000, options=0,
dispatchmgr=0x8083c000,
dispatchv4=0x864c9000, dispatchv6=0x864c9800) at view.c:580
#7 0x0041bba2 in configure_view (view=0xca46e800,
config=0x80abb4c0,
vconfig=0x8085ada8, mctx=0x8080d140, actx=0x7eff8860,
need_hints=isc_boolean_true)
at server.c:1290
#8 0x00420f42 in load_configuration (filename=Variable
filename is not available.
) at server.c:3285
#9 0x00422095 in loadconfig (server=0x8082f000) at server.c:4121
#10 0x00422426 in reload (server=0x8082f000) at server.c:4141
#11 0x004225c2 in ns_server_reloadcommand (server=0x8082f000,
args=Variable args is not available.
) at server.c:4334
#12 0x00407682 in ns_control_docommand (message=Variable
message is not available.
) at control.c:102
#13 0x0040a8b7 in control_recvmessage (task=0x80839000,
event=Variable event is not available.
) at controlconf.c:456
#14 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#15 0x005868a7 in thread_start ()
#16 0x in ?? ()
Cannot access memory at address 0x7eff9000
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin kirg...@corbina.net wrote:
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin kirg...@corbina.net 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).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M and
setting 'limits -v' to 512m).
3. Then the named process will eventually abort itself with a core dump
due to malloc failure. Please show us the stack trace at that point.
Hopefully it will reveal the malloc call that keeps consuming memory.
In fact, I myself successfully identified one leak in 9.5.0-P2 with
FreeBSD port this way.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
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
Re: dnsperf and BIND memory consumption
JINMEI Tatuya / 神明達哉 wrote: At Thu, 11 Dec 2008 11:25:42 +0300, Dmitry Rybin kirg...@corbina.net wrote: OK. I just make bind from src with ./configure --enable-threads gcc option -static. file /usr/local/sbin/named-test /usr/local/sbin/named-test: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 7.1 (701100), statically linked, FreeBSD-style, not stripped please let me check some points: 1. you used 9.5.1rc1 without any patch, right? 2. did you try 'rndc stop' at some point? If so, did named stop cleanly or did it abort itself? 3. were you periodically reloading the server during the test? I'm not sure if this is coincidence but the self-abort happened while reload operation in your both cases. 4. if the answer to question#2 is yes, is it possible to not reload the server and see if it changes anything? 5. is it possible to install (if not yet) libxml2 port to your system and enable statistics-channels? then you can see more detailed information about how named uses memory. 1. Yes. With STD_CDEFINES='-DFD_SETSIZE=16384' --enable-threads and static linking. 2. Cleanly 3. No. Then reloading result is the same. 4. 5. Yes. Building named with libxml2 done. Say me private your's IP to make access to it. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
OK. I just make bind from src with ./configure --enable-threads gcc
option -static.
file /usr/local/sbin/named-test
/usr/local/sbin/named-test: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), for FreeBSD 7.1 (701100), statically linked, FreeBSD-style,
not stripped
fresh system (yesterday cvsup to RELENG_7)
$ uname -a
FreeBSD XXX.XXX.XX 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Wed Dec 10
17:07:03 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/XXX amd64
2.
max-cache-size 128M;
start:
/usr/bin/limits -c 1000M -v 500M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
$ gdb -c named-test.core -se /usr/local/sbin/named-test
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Core was generated by `named-test'.
Program terminated with signal 6, Aborted.
#0 0x0058c3fc in thr_kill ()
[New Thread 0x80902f00 (LWP 100404)]
[New Thread 0x80902d80 (LWP 100400)]
[New Thread 0x80902c00 (LWP 100356)]
[New Thread 0x80902a80 (LWP 100318)]
[New Thread 0x80902900 (LWP 100239)]
[New Thread 0x80902780 (LWP 100237)]
[New Thread 0x80902600 (LWP 100222)]
[New Thread 0x80902480 (LWP 100209)]
[New Thread 0x80902300 (LWP 100175)]
[New Thread 0x80902180 (LWP 100092)]
[New Thread 0x80803180 (LWP 100177)]
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x00564247 in mem_getunlocked (ctx=0x8080d140, size=94) at
mem.c:385
#4 0x00564b68 in isc__mem_get (ctx=0x8080d140, size=94,
file=0x61bd78 rbt.c, line=1425) at mem.c:1096
#5 0x00480121 in create_node (mctx=0x8080d140,
name=0x7fbfcff0, nodep=0x7fbfd2e0) at rbt.c:1424
#6 0x0048080f in dns_rbt_addnode (rbt=0x80a925e8,
name=0x88cf2020, nodep=0x7fbfd3a8) at rbt.c:624
#7 0x0048be53 in loading_addrdataset (arg=0x94b07ff0,
name=0x88cf2020, rdataset=0x7fbfd810) at rbtdb.c:5657
#8 0x00463761 in commit (callbacks=0x7fbfe5c0,
lctx=0x80834000, head=0x7fbfe480, owner=0x88cf2020,
source=0x94c2afd8 co/brand.bak, line=611215) at master.c:2729
#9 0x004668df in load_text (lctx=0x80834000) at master.c:1427
#10 0x0046b61b in dns_master_loadfile2 (master_file=0x878a7098
co/broad.bak, top=Variable top is not available.
)
at master.c:2350
#11 0x00506126 in zone_load (zone=0x878ec000, flags=Variable
flags is not available.
) at zone.c:1504
#12 0x005082b9 in load (zone=Variable zone is not available.
) at zt.c:246
#13 0x00507ec2 in dns_zt_apply2 (zt=Variable zt is not available.
) at zt.c:379
#14 0x00508144 in dns_zt_load (zt=0x86adb750,
stop=isc_boolean_false) at zt.c:237
#15 0x004223c7 in load_zones (server=0x8082f000,
stop=isc_boolean_false) at server.c:3659
#16 0x004232fc in run_server (task=Variable task is not available.
) at server.c:3751
#17 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#18 0x005868a7 in thread_start ()
#19 0x in ?? ()
Cannot access memory at address 0x7fbff000
At normal situation after startup memory usage over 700 MB.
-
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
JINMEI Tatuya / 神明達哉 wrote:
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).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M
Re: dnsperf and BIND memory consumption
max-cache-size 64M;
# /usr/bin/limits -v 1200M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
Over 10 minutes of work and core dumped:
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x0056645a in isc_mem_createx2 (init_max_size=0, target_size=0,
memalloc=0x564400 default_memalloc, memfree=0x563320
default_memfree, arg=0x0,
ctxp=0xcb29b978, flags=Variable flags is not available.
) at mem.c:790
#4 0x00566730 in isc_mem_create (init_max_size=Variable
init_max_size is not available.
) at mem.c:859
#5 0x004d83ae in dns_resolver_create (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=Variable socketmgr is not available.
) at resolver.c:6514
#6 0x004ee860 in dns_view_createresolver (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=0x8082b000, timermgr=0x80829000, options=0,
dispatchmgr=0x8083c000,
dispatchv4=0x864c9000, dispatchv6=0x864c9800) at view.c:580
#7 0x0041bba2 in configure_view (view=0xca46e800,
config=0x80abb4c0,
vconfig=0x8085ada8, mctx=0x8080d140, actx=0x7eff8860,
need_hints=isc_boolean_true)
at server.c:1290
#8 0x00420f42 in load_configuration (filename=Variable
filename is not available.
) at server.c:3285
#9 0x00422095 in loadconfig (server=0x8082f000) at server.c:4121
#10 0x00422426 in reload (server=0x8082f000) at server.c:4141
#11 0x004225c2 in ns_server_reloadcommand (server=0x8082f000,
args=Variable args is not available.
) at server.c:4334
#12 0x00407682 in ns_control_docommand (message=Variable
message is not available.
) at control.c:102
#13 0x0040a8b7 in control_recvmessage (task=0x80839000,
event=Variable event is not available.
) at controlconf.c:456
#14 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#15 0x005868a7 in thread_start ()
#16 0x in ?? ()
Cannot access memory at address 0x7eff9000
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
JINMEI Tatuya / 神明達哉 wrote:
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).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M and
setting 'limits -v' to 512m).
3. Then the named process will eventually abort itself with a core dump
due to malloc failure. Please show us the stack trace at that point.
Hopefully it will reveal the malloc call that keeps consuming memory.
In fact, I myself successfully identified one leak in 9.5.0-P2 with
FreeBSD port this way.
---
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
Memory statistic
start - 570M
1 min - 913M
2 min - 958M
3 min - 1092M
4 min - 1074M
5 min - 1082M
10 min - 1217M
15 min - 1234M
60 min - 1513M
max-cache-size 800M;
Port installed only with Threads parameter, and patch in Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
===
# ps axw|grep named
/usr/local/sbin/named -t /var/named -u bind -c /etc/namedb/named.conf -t
/var/named -u bind
===
$ rndc status
version: 9.5.0-P2 (Unknown DNS1)
number of zones: 899
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 2
query logging is OFF
recursive clients: 286/9900/1
tcp clients: 0/100
server is up and running
===
(port installed)
$ldd /usr/local/sbin/named
/usr/local/sbin/named:
libcrypto.so.5 = /lib/libcrypto.so.5 (0x807bb000)
libthr.so.3 = /lib/libthr.so.3 (0x80a4d000)
libc.so.7 = /lib/libc.so.7 (0x80b63000)
(system standart)
$ldd /usr/sbin/named
/usr/sbin/named:
libcrypto.so.5 = /lib/libcrypto.so.5 (0x807a9000)
libthr.so.3 = /lib/libthr.so.3 (0x80a3b000)
libc.so.7 = /lib/libc.so.7 (0x80b51000)
===
ivan jr sy wrote:
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?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
JINMEI Tatuya / 神明達哉 wrote:
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).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
grep x86 work/bind-9.5.1rc1/config.log
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'
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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
