RE: Single nameserver doesn't show signed SOA-RRs
+ / let me guess / you use Smart Signing ? Weird, this week, in my verification of DNSSEC'd domains by our registrars I picked up exactly the same error : no RRSIG on the SOA. They filed a bug report to ISC about this. Might be related to this Smart Signing thing - can you confirm you are also using this ? Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Stefan Foerster [mailto:c...@incertum.net] Sent: 29 June 2011 10:57 PM To: bind-us...@isc.org Subject: Single nameserver doesn't show signed SOA-RRs Hello world, I'm having a problem with a single authoritative server that seems to not receive a signed zone. I used www.zonecheck.fr to check the zones incertum.net and billigmail.org and it complains that ns3.wars-nicht.de doesn't have a signed SOA. I already tried increasing the serial for those zones to retransfer them, but the error seems to persist. The affected nameserver is a Debian/lenny running 9.6.ESV.R4, the two other nameservers are Debian/squeeze running 9.7.3. On the affected nameserver, the only configuration with regards to DNSSEC was to add "dnssec-enable yes;" to the named configuration file (and restart it afterwards). Can anyone enlighten me on what I'm doing wrong here? I'd like to iron out this before I submit my keys to my registrar. Cheers Stefan ___ 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: Single nameserver doesn't show signed SOA-RRs
In message <20110630031511.gn14...@mail.incertum.net>, Stefan Foerster writes: > * Mark Andrews : > > Contact the adminstrator of the server and request that they stop > > disabling dnssec. "dnssec-enable yes;" is the default for all > > version except 9.3.x. > > Are you sure that 88.198.26.233 has DNSSEC disabled? The admin told me > he had added "dnssec-enable yes;" to the named.conf file. But has he reloaded/reconfigured the server? "dig billigmail.org any @88.198.26.233" shows the server has the signatures. "dig billigmail.org soa @88.198.26.233 +dnssec" show that they arn't being returned when requested and it also shows DO being returned which means there is nothing stripping out the DO bit on the way to the server or on the way back. > Cheers > Stefan > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Single nameserver doesn't show signed SOA-RRs
* Mark Andrews : > Contact the adminstrator of the server and request that they stop > disabling dnssec. "dnssec-enable yes;" is the default for all > version except 9.3.x. Are you sure that 88.198.26.233 has DNSSEC disabled? The admin told me he had added "dnssec-enable yes;" to the named.conf file. Cheers Stefan ___ 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: Single nameserver doesn't show signed SOA-RRs
Contact the adminstrator of the server and request that they stop disabling dnssec. "dnssec-enable yes;" is the default for all version except 9.3.x. % grep dnssec-enable 9.?.x/bin/named/config.c 9.3.x/bin/named/config.c: dnssec-enable no; /* Make yes for 9.4. */ \n\ 9.4.x/bin/named/config.c: dnssec-enable yes;\n\ 9.5.x/bin/named/config.c: dnssec-enable yes;\n\ 9.6.x/bin/named/config.c: dnssec-enable yes;\n\ 9.7.x/bin/named/config.c: dnssec-enable yes;\n\ 9.8.x/bin/named/config.c: dnssec-enable yes;\n\ % Mark In message <4e0bb211.2030...@provocation.net>, Zenon Panoussis writes: > > On 06/29/2011 10:57 PM, Stefan Foerster wrote: > > > ...it complains that ns3.wars-nicht.de doesn't have a > > signed SOA. > > It complains that the SOA of wars-nicht.de itself is not signed, or that > ns3.wars-nicht.de does not have a signed SOA for billigmail.org and > incertum.net? > > > I already tried increasing the serial for those zones to retransfer them, > > but the error seems to persist. > > Check whether the zone transfer actually took place. Even if you increase > the serial and send notifies, there could be a misconfiguration somewhere > preventing the notifies from getting through or the tranfer from taking > place. > > Looking at them now, all three seem to have the same serial, 2011062902 > for both domains. > > Z > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Single nameserver doesn't show signed SOA-RRs
On 06/29/2011 10:57 PM, Stefan Foerster wrote: > ...it complains that ns3.wars-nicht.de doesn't have a > signed SOA. It complains that the SOA of wars-nicht.de itself is not signed, or that ns3.wars-nicht.de does not have a signed SOA for billigmail.org and incertum.net? > I already tried increasing the serial for those zones to retransfer them, > but the error seems to persist. Check whether the zone transfer actually took place. Even if you increase the serial and send notifies, there could be a misconfiguration somewhere preventing the notifies from getting through or the tranfer from taking place. Looking at them now, all three seem to have the same serial, 2011062902 for both domains. Z ___ 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: better performance with 32 bit ! why?
Michael Graff wrote: > We hope to improve this in 9.9 or at the latest 9.10, and have something > that can saturate all CPUs. And no, we're not cracking RSA keys on the > extra CPUs just to keep them busy! Pre-populating a small /56 IPv6 prefix with PTRs? :-) I'm looking forward to what you're planning for 9.something - I still have more cores I could in theory gain some speed from. Regards Eivind Olsen ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 4:28 PM, Sven Eschenberg wrote: > P.S.: If all parts of bind were optimized towards multicore processing and > the pattern of queries fits, yes, then the 8 core machine could probably > outrun the 4 core machine, even when having a slower clock. But this might > worsen the performance on single or dual core CPUs on the other hand. We hope to improve this in 9.9 or at the latest 9.10, and have something that can saturate all CPUs. And no, we're not cracking RSA keys on the extra CPUs just to keep them busy! - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC6rwAAoJEDRzoY2A7tzbS9YH/2t6ohywrYjmX6xvg/Dshq5F 7cjirVvoE4jCarVREPWoL3vTAEUmehMccSIq6NRw9Uqb/Mrwa/UoNe9lN0D9r5zy 47trPsORG3kQW0T+znkO4zizlC4goKS4MBjasuXMKOYMtSizdi4pRBWBI6uaVgdG fnGhPpK6s6bKFpH7labYnz32cBQW1P9FxyNV+aFgW/A8EJdhRbEMrTsbZHYFpoQO mpVuvYoQOljCfjYhqpch/hsxdGdJO2w2XIqLpbWe4Etdt7OScuCbWfhmTnVrFP2Q J6fcx2WmrHh5neOWkGe7jEanPBG6ajrMyBUZH5qClVQTYPYRu9TlRgti7RFCm3M= =ndSh -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
That is, if all of those threads have work to do, because the task can be distributed accordingly. Which is not easy even if you know the number of cores (threads for that matter) and the whole task is known a priori. Unfortunately Queries to a DNS-Server like bind do not follow parameters known a priori, so distributing the tasks (work) to threads with the goal of equal load aswell as minimum response time is an online-scenario and all but trivial. ;-) Regards -Sven P.S.: If all parts of bind were optimized towards multicore processing and the pattern of queries fits, yes, then the 8 core machine could probably outrun the 4 core machine, even when having a slower clock. But this might worsen the performance on single or dual core CPUs on the other hand. On Wed, June 29, 2011 19:58, Lightner, Jeff wrote: > I'm not sure I agree with that - multiple single threaded processes can > be distributed across cores/CPUs. That is to say ONE single thread > process doesn't gain from multiple cores but more than one can because > they don't have to compete against each other on the same core. > > -Original Message- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf > Of Ryan Novosielski > Sent: Wednesday, June 29, 2011 9:59 AM > To: iharrathi@orange-ftgroup.com > Cc: bind-users@lists.isc.org > Subject: Re: better performance with 32 bit ! why? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Not necessarily. They are not apples to apples. Multi-core machines only > excel at multi-threaded computational loads. I don't know how BIND does > or does not qualify. I suspect, however, there may be some other > differences between the two chips anyhow (cache size differences, etc.). > > On 06/29/2011 09:33 AM, iharrathi@orange-ftgroup.com wrote: >> on server1(64 bit) i have 2 Intel E5310 *quad*-core 1.6Ghz and on >> server2(32 bit) i have 2 Intel Xeon *dual*-core 2.33Ghz. >> means 8*1.6 Ghz on server1 and 4*2.33 on server2. >> >> 8*1.6 is better and faster than 4*2.33, no? >> // >> /Regards / >> /Issam Harrathi./ >> >> >> >>>/ The 64 bit server(server1) is faster than the 32 bit server > (server2). >> / >> Really? I thought you said the 64 bit server had a CPU with 1.6GHz > cores, >> and the 32 bit server had 2.33GHz cores? >> >> Regards >> Eivind Olsen >> >> > > >> IMPORTANT.Les informations contenues dans ce message electronique y > compris les fichiers attaches sont strictement confidentielles >> et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) > destinataire(s) mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas > destine, veuillez immediatement le signaler a l expediteur et effacer > ce message >> et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues > dans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite > notamment s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de > tout virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly > confidential and may be protected by law. This message is >> intended only for the named recipient(s) above. >> If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this > e-mail message. >> Any unauthorized view, usage or disclosure ofthis message is > prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall > not be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> > > >> >> >> >> ___ >> 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 > > > - -- > - _ _ _ _ ___ _ _ _ > |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer > |$&| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) > \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4LL5gACgkQmb+gadEcsb7iMwCg08huQWUMJ/I2COhwc7mzN5ix > 6mwAnifUFtFJi5fQb10Tpf1iaul9Nn7X > =HbQB > -END PGP SIGNATURE- > > Proud partner. Susan G. Komen for the Cure. > > Please consider our environment before printing this e-mail or > attachments. > --
Re: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 3:00 PM, Sven Eschenberg wrote: > One thing that just popped up my mind: > Does it increase performance, when you, let's say, bind multiple IPs to > the same NIC and make bind listen to all of those IPs, while of course > taking care to fix the corresponding NS RRs to contact all of thos IPs. In general, yes. If the NIC can handle the data flow well, and the OS kernel can handle the multiple UDP sockets well. I've seen some people "work around" BIND 9's implementation by using 3 sockets on the same host, either on different IP addresses or on different ports, and use an external load balancer to make them appear as a singe entity to the outside world, as well as allow them to be used directly if on different addresses. ISC is addressing this limitation. It's pretty clear more cores are in our future, not more CPU per core. *hugs his 8-core 3.00 Ghz Xeon box* :) A lot of work has been done in TCP-land to enable web applications, and this means UDP has somewhat fallen to the wayside. After all, there aren't a lot of applications that use UDP and really expect high data rates, right? :) I've seen some kernels (to remain nameless) that use one giant lock for all UDP input in the kernel, and while this is a short-lived lock, it is a contention point. If listening on more than one socket still has this bottleneck there isn't much to do about it. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC5e1AAoJEDRzoY2A7tzbQBkH/0/4PHvUKK6/fxw4/s5P+8Oy V3+RqCF3P1rSNAxnjJNv0r7Lcbflene/zCUol7/wjob20vpLdld5ummRPo76H5vZ gm5rIbYRZQ7W85dTT++f+rOawO7g6DEJNB3vJvH4WucoON4dhfSL4IMHkE0eWxEs 3nhG7bp6yExoXlO10Ug4LzDMux8saYBykWkGOBJSXCQ8eZfs5dPMU/N1DcjXgYUg h5UGgS8l4QfIycidcPen62VOdExrNEjD36E8tDBv/SA8U+D0wLfYRbptvvSsx5kT 5OYL3tkB8A0nsodHsj2cjnl3KclElN0yZTqYPf/ZOn0kfdsBkPc0lc2a0q0uGGU= =GyI9 -END PGP SIGNATURE- ___ 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
Single nameserver doesn't show signed SOA-RRs
Hello world, I'm having a problem with a single authoritative server that seems to not receive a signed zone. I used www.zonecheck.fr to check the zones incertum.net and billigmail.org and it complains that ns3.wars-nicht.de doesn't have a signed SOA. I already tried increasing the serial for those zones to retransfer them, but the error seems to persist. The affected nameserver is a Debian/lenny running 9.6.ESV.R4, the two other nameservers are Debian/squeeze running 9.7.3. On the affected nameserver, the only configuration with regards to DNSSEC was to add "dnssec-enable yes;" to the named configuration file (and restart it afterwards). Can anyone enlighten me on what I'm doing wrong here? I'd like to iron out this before I submit my keys to my registrar. Cheers Stefan ___ 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: better performance with 32 bit ! why?
Thanks for that insight. I already considered something like the 'single core per udp socket' problem. One thing that just popped up my mind: Does it increase performance, when you, let's say, bind multiple IPs to the same NIC and make bind listen to all of those IPs, while of course taking care to fix the corresponding NS RRs to contact all of thos IPs. (I'm thinking of something like: in NS ns1 in NS ns2 ns1 in a ip1 ns1 in a ip2 ... ns2 in a ipa ns2 in a ipb ... While ip1 and ip2 in the example are on the same NIC ) If I understood you right, this should probably scale better on machines with a high number of cores and improve the number of queries that can be processed. More available UDP sockets should lead to more cores being used for the initial IO stuff. I am just asking out of curiosity though. Regards -Sven On Wed, June 29, 2011 18:49, Michael Graff wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 6/29/11 9:08 AM, Sven Eschenberg wrote: > >> Maybe some bind developer can shed a light on this: >> Does bind use epoll()? >> AIO (as in Posix RT extensions) > > BIND 9 uses epoll() I believe, but AFAIK does not touch AIO. I've not > touched that code recently though, so this is possibly out of date > information. Also, which version of BIND 9.x introduced the epoll() I > am not certain of. > > That said, the single biggest problem in BIND 9 currently in terms of > using all CPUs on a high-core machine is that all initial I/O is > processed on a single core per UDP socket. > > Thus, you had 32 real cores in a server today and would use this beast > for DNS, you'd not be happy unless you somehow spread this across > multiple UDP listening sockets. > > We're working on this though. As with all things, we work on the things > that are most important to our customers and users, so making your voice > heard that this is important is helpful to us. Running code is always > good too, as is a monetary donation for a development effort you want to > see moving forward faster. > > - --Michael > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOC1eJAAoJEDRzoY2A7tzbOTYH+wZUawX9R+dH6weqxXlyTLL+ > 48OtpAh/DHDyPGFCa7O3IDuYdvNr455oAoSzN4qSLV/gEAKsRCLC3mxa90Fit367 > r4goLR4uC96DYMKWdUJzsruxqeyUcET1xbNRWiz+g5M40ZJf0YYpW4mIlGls+9UP > lXyFiCAxESTmklYNrwTy++m4Hz8JjuV9FsbXzvlu0IyQR+qdbsZ3xYleHblawb1b > Q57hpXvcmpxI4e7hRrj0Q2QdfZKk87+LXiErWbhaqui/hOw89PAlF7HR1J8vwLtj > maBil2+UV3kSUtF3EVoFasuQKUTYWM14uqYA4Eu3RbHWVf4VJuZ1+gB3dhtbBh0= > =7Qi6 > -END PGP SIGNATURE- > ___ > 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 > ___ 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: better performance with 32 bit ! why?
I'm not sure I agree with that - multiple single threaded processes can be distributed across cores/CPUs. That is to say ONE single thread process doesn't gain from multiple cores but more than one can because they don't have to compete against each other on the same core. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Ryan Novosielski Sent: Wednesday, June 29, 2011 9:59 AM To: iharrathi@orange-ftgroup.com Cc: bind-users@lists.isc.org Subject: Re: better performance with 32 bit ! why? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not necessarily. They are not apples to apples. Multi-core machines only excel at multi-threaded computational loads. I don't know how BIND does or does not qualify. I suspect, however, there may be some other differences between the two chips anyhow (cache size differences, etc.). On 06/29/2011 09:33 AM, iharrathi@orange-ftgroup.com wrote: > on server1(64 bit) i have 2 Intel E5310 *quad*-core 1.6Ghz and on > server2(32 bit) i have 2 Intel Xeon *dual*-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > > 8*1.6 is better and faster than 4*2.33, no? > // > /Regards / > /Issam Harrathi./ > > > >>/ The 64 bit server(server1) is faster than the 32 bit server (server2). > / > Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, > and the 32 bit server had 2.33GHz cores? > > Regards > Eivind Olsen > > > IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > > > > ___ > 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 - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LL5gACgkQmb+gadEcsb7iMwCg08huQWUMJ/I2COhwc7mzN5ix 6mwAnifUFtFJi5fQb10Tpf1iaul9Nn7X =HbQB -END PGP SIGNATURE- Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 9:16 AM, iharrathi@orange-ftgroup.com wrote: > Do i have to use bind compiled and running on 32 bit server to have > better performance rather than bind compiled and running on 64 bit server? No matter what, what gets you the best performance is what you should choose to do. BIND 9 does not currently benefit as much from more cores, but does from more powerful cores. I suspect this is what is happening in your tests. The 4 core machine is able to be fully utilized, and each core is faster. In the 8 core machine, you are not only doubling the amount of data needed to be moved around in some cases, you are lowering the core speed. If BIND uses perhaps 6 of the cores, with the typical 64-bit overhead of more data and more effort on the system, you are losing performance. Also, like mentioned by several here, you are not using identical machines. When you benchmark and compare results, you want to minimize the differences or at least account for them. Your machine is not just made of CPUs, it has memory (which may vary in speed), network cards and the drivers (which may be better or worse depending in the card and drivers), and motherboard chipsets in use. There are just too many variables to account for in your comparison that we cannot really help with. Thus, the only answer that is ultimately important to you is, on this new hardware, how can I make BIND 9 run fastest? If that turns out to be a 32-bit OS or a 32-bit named binary, that's your answer. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC2bZAAoJEDRzoY2A7tzbkf8H/iIOCnEUfz8p6AtTBzuxcRag z5R4f4C9vVd2MtqvYbN4BxrLz8dfqlgYM4ZAtIB7HyQnFnkeNuxIiqc1PDec6866 mpk/COSF+RP+mzMqenEbWcYOPl/giVq/0qFL+oqiD9Fq4PQCltsgCwMSf65fLdgH CoutRsM8AAO3cJ6N80PIlAMe0kocP6K/MBGJyaJznKhZR/TusKCdRP9cg9xc9h51 Y6XlflaOE6EKXq9pv49JupUxSN6Fk5pVJ+jsBmr6wLroQIZpVZRK9Zm2idbvtrC5 L8EaeDgeYNJRCNglOT5kwYydAt/g3SvGkgm9Q1zNk+HqX18EeNTNqZqK31yETBo= =ZSz9 -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 9:08 AM, Sven Eschenberg wrote: > Maybe some bind developer can shed a light on this: > Does bind use epoll()? > AIO (as in Posix RT extensions) BIND 9 uses epoll() I believe, but AFAIK does not touch AIO. I've not touched that code recently though, so this is possibly out of date information. Also, which version of BIND 9.x introduced the epoll() I am not certain of. That said, the single biggest problem in BIND 9 currently in terms of using all CPUs on a high-core machine is that all initial I/O is processed on a single core per UDP socket. Thus, you had 32 real cores in a server today and would use this beast for DNS, you'd not be happy unless you somehow spread this across multiple UDP listening sockets. We're working on this though. As with all things, we work on the things that are most important to our customers and users, so making your voice heard that this is important is helpful to us. Running code is always good too, as is a monetary donation for a development effort you want to see moving forward faster. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC1eJAAoJEDRzoY2A7tzbOTYH+wZUawX9R+dH6weqxXlyTLL+ 48OtpAh/DHDyPGFCa7O3IDuYdvNr455oAoSzN4qSLV/gEAKsRCLC3mxa90Fit367 r4goLR4uC96DYMKWdUJzsruxqeyUcET1xbNRWiz+g5M40ZJf0YYpW4mIlGls+9UP lXyFiCAxESTmklYNrwTy++m4Hz8JjuV9FsbXzvlu0IyQR+qdbsZ3xYleHblawb1b Q57hpXvcmpxI4e7hRrj0Q2QdfZKk87+LXiErWbhaqui/hOw89PAlF7HR1J8vwLtj maBil2+UV3kSUtF3EVoFasuQKUTYWM14uqYA4Eu3RbHWVf4VJuZ1+gB3dhtbBh0= =7Qi6 -END PGP SIGNATURE- ___ 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
Large number of small zones in BIND? We have something for you to try.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've been working on the start-up time of BIND 9, when many many zones are configured. By many, I mean in the 10k to 1m range. If you are someone who has a large number of zones loaded into BIND 9, and would like to try out some test code to see if our work improves your load time, please contact me. This is another CPU time / memory trade-off, but we don't think the overhead will be significant. If you choose to test, we will want you to report your original and hopefully-improved start-up time, original and new memory usage, and of course any problems you encounter. I have set the reply-to address for this mail to myself; if you want to discuss this on the list, please do so but set it back to the list address. Thanks! Please include the following: Number of zones loaded: BIND 9 version in use: Can you test with a different, developmental version? Would you test in your lab or production? If we got code to you this or next week, when could you complete your measurements? - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC1J4AAoJEDRzoY2A7tzb9qkH/j6ruhDfJjvZrwOlK67y6Txs R/jcQuMcJxLOwxFDl2+Rl6SGEBAc7AuK7sZRZxlAlxd6UFyLP3t9NHqkHHizdXKX 0/k85mbAS+BKaJ7s9kc4nr/54bYSqx/seaTPBE5Jz8z+0PqBzsRxveDLWDvcETyp DM/ck5Zs8CoyL5w4pv3kKM7u3v3XMXb2G3egvM3VS38n7qyd86+Czq0W0hCHnhaB 6yZh5Ms9oYzkzINYRQAr5Hhk09Kvw++wVfEQ2dFdxYYWs5eHQDq8MWC4CbWs4fqZ 9p1hc61uycCpglUaP9FcLiapzsVWlIvsYPY4uoh1DZYmwpoahuW7ZIQylOx9dI0= =M6cr -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 8:19 AM, Eivind Olsen wrote: > Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, > and the 32 bit server had 2.33GHz cores? Benchmarking on different machine types, even if they are identical speed, can be affected by any number of issues: ethernet card type, motherboard chipset, etc. Even features chosen on an identical chipset. For true comparison, one must run the 32-bit OS on the same hardware (not just "similar" hardware) to do a direct comparison. That said, more is not always better. 64-bit means it can move more memory around faster in certain circumstances, and it can address more than 4 GB without pulling special hardware tricks. That said, it MUST move around double the memory in certain operations, like pointers. BIND 9 uses a fair number of pointers, so often times the overhead increases faster than the benefit of a larger accessible memory area. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC0ErAAoJEDRzoY2A7tzb+sgH/2svm6VPTa8OTm6L3H+Rq0QY 5pHQsT55GoclIZ+ttTQBouz8bla4QIJ53Cwjpw1bnBFrH6LEIR0vWDalBA5RUmX/ 7ZVqShxhvI2MfpYaramFJEjocDMcDxxt4mmFk+StvqATaENJSaqfXxpXHpqViDoK Et5a+npBaHfqPCyVWKO3VUlgSMhqFo6xIUSGhuXl7spe65zPEBfat5/Kea8S+puS wynsW+M7/Steqh5yLOdN9oD/wWQNSqOXSRZFpGliZNuFyrk90dWB0T+cyXMki7Jd Ls+fAyE7Z0jKPJIE0ttgJ0ditSXOFzW4oQmMfxd4eN+WzTDRXAF/zJUcsvGCMos= =IwZR -END PGP SIGNATURE- ___ 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: Re: better performance with 32 bit ! why?
As asked, i will made a test with os 32 bit on the same server as the the 64 bit, and will post this result here. Thanks for all for your answers. Regards. Issam Harrathi. De : HARRATHI Issam Ext OLNC/DPS Envoyé : mercredi 29 juin 2011 16:17 À : 's...@whgl.uni-frankfurt.de'; 'Ryan Novosielski'; 'eiv...@aminor.no'; 'dufb...@telia.net'; 'lst_ho...@kwsoft.de' Cc : 'bind-users@lists.isc.org' Objet : Re: better performance with 32 bit ! why? When i start Bind on server2 i do it with -n 4 ( to use 4 thread) and on server1 i start bind with -n 8. And i see then on munin that the load is shared on all cores. For the load-server it's another server let's call it server 3. I know that tcpreplay is monothread so i lunch 2*25000 qps for example. And i use also resperf for testing, what i have with resperf and tcpreplay is nearly the same. What's important is that i 'm using always the same server3 to load the server1 and server2 (not at the same time, and using the same pcap-- rewrite twice to meet the mac@ of server1 and server2-- ) and i start with -n 4 on the 4 cores server and with -n 8 on the 8 cores. But i found best performance on the 32 bit server2 (4*2.33). Other information i begin the test only after sending for a few minutes 2 qps, so then i have only 5% of request that causes recursion, and about 15% nxdoamin answer, finally 80% of answer from cache. This is available for the 2 server since it's the same original pcap written twice. Do i have to use bind compiled and running on 32 bit server to have better performance rather than bind compiled and running on 64 bit server? and to be more clear this is the last core of the 64 bit server: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz stepping: 11 cpu MHz : 1600.058 cache size : 4096 KB physical id : 1 siblings: 4 core id : 3 cpu cores : 4 apicid : 7 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips: 3177.52 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: and this is the last core of the 32 bit server: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5140 @ 2.33GHz stepping: 11 cpu MHz : 2333.389 cache size : 4096 KB physical id : 3 siblings: 2 core id : 7 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est tm2 xtpr bogomips: 4666.97 Regards. Issam Harrathi Issam Harrathi wrote: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > 8*1.6 is better and faster than 4*2.33, no? You can only do maths like that if you assume that everything is multithreaded _and_ capable of spreading to multiple cores without any overhead. I've mentioned earlier that for example BIND only scales up to about 4 threads. Based on this, your maths example would be (kind of simplified): 64 bit vs 32 bit: 4*1.6GHz vs 4*2.33GHz Also, you mentioned using tcpreplay, which is also apparantly single-threaded , making the comparison like this: 1*1.6GHz vs 1*2.33GHz. Regards Eivind Olsen IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by la
Re: better performance with 32 bit ! why?
On Wed, Jun 29, 2011 at 8:33 PM, wrote: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > > 8*1.6 is better and faster than 4*2.33, no? Sometimes I wonder if people REALLY read the replies sent to the list. If they don't read it, then why bother asking? David has mentioned that the reason your "32bit server" is faster is because it has higher clock speed (2.33 GHz). Elvin has also mentioned that the 32 bit 2.33GHz CPU might actually win out purely based on the higher clock frequency. Basically what they're saying is that for BIND, clock speed of a SINGLE core is more important that the TOTAL sum of all core speeds. So if you've read their response you wouldn't say "8*1.6 is better and faster than 4*2.33". Cause the total doesn't matter in this case. >From my experience: - clock speed of a SINGLE core matters. A lot. - going from 2 cores to 4 cores give about 50% improvement, but going from 4 to 8 cores doesn't give any signifcant improvement - x86_64 simply kick ass compared to power or sparc. Stick with x86_64 if If you're using BIND, don't bother with other arch (which are more expensive, give lower performance. At least it was true at that time). - 64 bit OS and userland gives the benefit of more addressable memory. In BIND's case, this means more memory for cache, which (depends on the type of load) can lead to higher performance (only if you configure it to use the memory for cache, of course). -- Fajar ___ 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: better performance with 32 bit ! why?
On 29.06.11 15:33, iharrathi@orange-ftgroup.com wrote: on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 bit) i have 2 Intel Xeon dual-core 2.33Ghz. means 8*1.6 Ghz on server1 and 4*2.33 on server2. 8*1.6 is better and faster than 4*2.33, no? It was already explained to you that bind does not scale much better with more than 4 threads. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody ___ 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: better performance with 32 bit ! why?
When i start Bind on server2 i do it with -n 4 ( to use 4 thread) and on server1 i start bind with -n 8. And i see then on munin that the load is shared on all cores. For the load-server it's another server let's call it server 3. I know that tcpreplay is monothread so i lunch 2*25000 qps for example. And i use also resperf for testing, what i have with resperf and tcpreplay is nearly the same. What's important is that i 'm using always the same server3 to load the server1 and server2 (not at the same time, and using the same pcap-- rewrite twice to meet the mac@ of server1 and server2-- ) and i start with -n 4 on the 4 cores server and with -n 8 on the 8 cores. But i found best performance on the 32 bit server2 (4*2.33). Other information i begin the test only after sending for a few minutes 2 qps, so then i have only 5% of request that causes recursion, and about 15% nxdoamin answer, finally 80% of answer from cache. This is available for the 2 server since it's the same original pcap written twice. Do i have to use bind compiled and running on 32 bit server to have better performance rather than bind compiled and running on 64 bit server? and to be more clear this is the last core of the 64 bit server: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz stepping: 11 cpu MHz : 1600.058 cache size : 4096 KB physical id : 1 siblings: 4 core id : 3 cpu cores : 4 apicid : 7 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips: 3177.52 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: and this is the last core of the 32 bit server: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5140 @ 2.33GHz stepping: 11 cpu MHz : 2333.389 cache size : 4096 KB physical id : 3 siblings: 2 core id : 7 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est tm2 xtpr bogomips: 4666.97 Regards. Issam Harrathi Issam Harrathi wrote: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > 8*1.6 is better and faster than 4*2.33, no? You can only do maths like that if you assume that everything is multithreaded _and_ capable of spreading to multiple cores without any overhead. I've mentioned earlier that for example BIND only scales up to about 4 threads. Based on this, your maths example would be (kind of simplified): 64 bit vs 32 bit: 4*1.6GHz vs 4*2.33GHz Also, you mentioned using tcpreplay, which is also apparantly single-threaded , making the comparison like this: 1*1.6GHz vs 1*2.33GHz. Regards Eivind Olsen IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are act
Re: better performance with 32 bit ! why?
Not neccessarily. It really depends on many many things. How well does the OS kernel+NIC driver scale, how good do they work in balancing among all CPUs+cores. I do not know the inner workings of bind, but depending on the algorithmic problems, distributed/parallel processing can even degrade performance, sometimes the gain in distribution is not as good as expected due to communication overhead etc. . So the assumption that 8@1.6>>4@2.33 can not be safely made. Especially in a single application scenario (A pure name server). Maybe some bind developer can shed a light on this: Does bind use epoll()? AIO (as in Posix RT extensions) As stated by others, use the same machine for all 3 scenarios (OS/Apps): 32/32 64/32 64/64 Regards -Sven On Wed, June 29, 2011 15:33, iharrathi@orange-ftgroup.com wrote: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > > 8*1.6 is better and faster than 4*2.33, no? > > Regards > Issam Harrathi. > > > >> The 64 bit server(server1) is faster than the 32 bit server (server2). > > Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, > and the 32 bit server had 2.33GHz cores? > > Regards > Eivind Olsen > > > IMPORTANT.Les informations contenues dans ce message electronique y > compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, > veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues > dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite > notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout > virus. > > IMPORTANT.This e-mail message and any attachments are strictly > confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e-mail > message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not > be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > > ___ > 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 ___ 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: Named.conf logical blocks
On 06/29/2011 02:37 PM, Chris Buxton wrote:
Not entirely. There is at least one construct that looks like this (using your
terms):
thing+ block thing block semicolon
For example, within the controls statement:
inet * allow { trusted; } keys { some.key; };
Good point.
___
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: better performance with 32 bit ! why?
It would be interesting to hear what kind of lookup that you did for your test. Did the servers just answer from configured zones? Would recursion make any difference on the utilization of the cores? And validation? Or is four fast cores always better than many slower cores? Mats iharrathi@orange-ftgroup.com skrev 2011-06-29 15:33: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > > 8*1.6 is better and faster than 4*2.33, no? > > Regards > Issam Harrathi. > > > >> The 64 bit server(server1) is faster than the 32 bit server (server2). > > Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, > and the 32 bit server had 2.33GHz cores? > > Regards > Eivind Olsen > > > IMPORTANT.Les informations contenues dans ce message electronique y compris > les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, > veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans > ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment s > il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout > virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential > and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e-mail > message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not be > liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > > > > > > ___ > 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 ___ 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: better performance with 32 bit ! why?
Zitat von iharrathi@orange-ftgroup.com: on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 bit) i have 2 Intel Xeon dual-core 2.33Ghz. means 8*1.6 Ghz on server1 and 4*2.33 on server2. 8*1.6 is better and faster than 4*2.33, no? This would only apply for applications with ideal scalability. Most applications are limited by some serial code paths which only benefits from higher clock speed. So no, you cannot simply add core*clockspeed to compare. For more on this topic see for example http://en.wikipedia.org/wiki/Amdahl%27s_law Regards Andreas ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not necessarily. They are not apples to apples. Multi-core machines only excel at multi-threaded computational loads. I don't know how BIND does or does not qualify. I suspect, however, there may be some other differences between the two chips anyhow (cache size differences, etc.). On 06/29/2011 09:33 AM, iharrathi@orange-ftgroup.com wrote: > on server1(64 bit) i have 2 Intel E5310 *quad*-core 1.6Ghz and on > server2(32 bit) i have 2 Intel Xeon *dual*-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > > 8*1.6 is better and faster than 4*2.33, no? > // > /Regards / > /Issam Harrathi./ > > > >>/ The 64 bit server(server1) is faster than the 32 bit server (server2). > / > Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, > and the 32 bit server had 2.33GHz cores? > > Regards > Eivind Olsen > > > IMPORTANT.Les informations contenues dans ce message electronique y compris > les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, > veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans > ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment s > il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout > virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential > and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e-mail > message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not be > liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > > > > > ___ > 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 - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LL5gACgkQmb+gadEcsb7iMwCg08huQWUMJ/I2COhwc7mzN5ix 6mwAnifUFtFJi5fQb10Tpf1iaul9Nn7X =HbQB -END PGP SIGNATURE- <>___ 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: better performance with 32 bit ! why?
Issam Harrathi wrote: > on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 > bit) i have 2 Intel Xeon dual-core 2.33Ghz. > means 8*1.6 Ghz on server1 and 4*2.33 on server2. > 8*1.6 is better and faster than 4*2.33, no? You can only do maths like that if you assume that everything is multithreaded _and_ capable of spreading to multiple cores without any overhead. I've mentioned earlier that for example BIND only scales up to about 4 threads. Based on this, your maths example would be (kind of simplified): 64 bit vs 32 bit: 4*1.6GHz vs 4*2.33GHz Also, you mentioned using tcpreplay, which is also apparantly single-threaded , making the comparison like this: 1*1.6GHz vs 1*2.33GHz. Regards Eivind Olsen ___ 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: Named.conf logical blocks
On Jun 29, 2011, at 12:21 AM, Phil Mayers wrote:
> Or use Config::Parser, or adapt the script I sent round (which in fact was
> the reason I wrote it); tokenisation of the bind config file is easy, and the
> core grammar is straightforward because everything is ;-terminated, with the
> form:
>
> item = thing+ block semicolon
> thing = word | quoted-string
> block = { item+ }
Not entirely. There is at least one construct that looks like this (using your
terms):
thing+ block thing block semicolon
For example, within the controls statement:
inet * allow { trusted; } keys { some.key; };
Regards,
Chris Buxton
BlueCat Networks
___
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: better performance with 32 bit ! why?
on server1(64 bit) i have 2 Intel E5310 quad-core 1.6Ghz and on server2(32 bit) i have 2 Intel Xeon dual-core 2.33Ghz. means 8*1.6 Ghz on server1 and 4*2.33 on server2. 8*1.6 is better and faster than 4*2.33, no? Regards Issam Harrathi. > The 64 bit server(server1) is faster than the 32 bit server (server2). Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, and the 32 bit server had 2.33GHz cores? Regards Eivind Olsen IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ 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: better performance with 32 bit ! why?
iharrathi@orange-ftgroup.com wrote: > The 64 bit server(server1) is faster than the 32 bit server (server2). Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, and the 32 bit server had 2.33GHz cores? Regards Eivind Olsen ___ 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: better performance with 32 bit ! why?
The 64 bit server(server1) is faster than the 32 bit server (server2). >Tests: >Test1: OS 64 bit, bind 64 bit ==> 5 qps server1 >Test2: OS 32 bit, bind 32 bit ==> 7 qps server2 >Test3: OS 64 bit, bind 32 bit ==> 5 qps server1 -- Message: 5 Date: Wed, 29 Jun 2011 13:39:43 +0200 From: Matus UHLAR - fantomas Subject: Re: bind-users Digest, Vol 902, Issue 1 To: bind-users@lists.isc.org Message-ID: <20110629113943.gb3...@fantomas.sk> Content-Type: text/plain; charset=us-ascii; format=flowed On 29.06.11 11:04, iharrathi@orange-ftgroup.com wrote: >@ Andreas i made the test and i have the same performance as OS 64 bind 64. >NB: when i reach the maximum throughput i still have enough free RAM, > free CPU, free NIC capacity. So the limit is in Bind. What to do to > reach more capacity? Get faster CPU. Or get a L3 switch and more machines behind it. >Tests: >Test1: OS 64 bit, bind 64 bit ==> 5 qps >Test2: OS 32 bit, bind 32 bit ==> 7 qps >Test3: OS 64 bit, bind 32 bit ==> 5 qps Did you try this on the same maching, or are you still using 32-bit OS on machine with faster CPU and 64-bit OS on slower CPU-machine? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 902, Issue 2 ** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ 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: bind-users Digest, Vol 902, Issue 1
On 29.06.11 11:04, iharrathi@orange-ftgroup.com wrote: @ Andreas i made the test and i have the same performance as OS 64 bind 64. NB: when i reach the maximum throughput i still have enough free RAM, free CPU, free NIC capacity. So the limit is in Bind. What to do to reach more capacity? Get faster CPU. Or get a L3 switch and more machines behind it. Tests: Test1: OS 64 bit, bind 64 bit ==> 5 qps Test2: OS 32 bit, bind 32 bit ==> 7 qps Test3: OS 64 bit, bind 32 bit ==> 5 qps Did you try this on the same maching, or are you still using 32-bit OS on machine with faster CPU and 64-bit OS on slower CPU-machine? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. ___ 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: Better solution than making a recursive nameserver authoritative?
On 24.06.11 13:39, David Coulthart wrote: Currently the two recursive caching nameservers for clients on our network are also authoritative for a few zones. In particular, they are authoritative for: 1) our main forward zone (columbia.edu) in order to provide an internal view of the zone 2) RFC 1918 reverse zones (e.g., 10.in-addr.arpa) Then they do exactly what internal nameservers are supposed to do. I would like to follow best practices by separating authoritative & recursive functionality. The practice comes out of the need to provide correct DNS data in case you have configured a zone that is not anymore delegated to your server and is obsolete. This practice appears not to apply for your company's main domain, unless you loose it and someone else claims it. Especially if it's your internal version. Therefore, I see no need for you to configure new server for those zones, you seem to have exactly what you need. Also, when I sign these zones, I would like the recursive nameservers to respond with the AD bit set instead of AA. I don't see any reason why you should sign the internal and rfc1918 (and probably rfc5735) zones. What is the point of wanting this? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler ___ 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: better performance with 32 bit ! why?
-Message d'origine- De : HARRATHI Issam Ext OLNC/DPS Envoyé : mercredi 29 juin 2011 11:04 À : 'novos...@umdnj.edu'; 'lst_ho...@kwsoft.de'; 'kob6...@gmail.com' Cc : 'bind-users@lists.isc.org' Objet : RE: bind-users Digest, Vol 902, Issue 1 Thanks for the answer, @ Andreas i made the test and i have the same performance as OS 64 bind 64. NB: when i reach the maximum throughput i still have enough free RAM, free CPU, free NIC capacity. So the limit is in Bind. What to do to reach more capacity? Tests: Test1: OS 64 bit, bind 64 bit ==> 5 qps Test2: OS 32 bit, bind 32 bit ==> 7 qps Test3: OS 64 bit, bind 32 bit ==> 5 qps Regards Issam Harrathi. Message: 7 Date: Wed, 29 Jun 2011 09:16:01 +0200 From: lst_ho...@kwsoft.de Subject: Re: better performance with 32 bit ! why? To: bind-users@lists.isc.org Message-ID: <20110629091601.30282lyntw1u4...@webmail.kwsoft.de> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Zitat von Kevin Oberman : > On Tue, Jun 28, 2011 at 7:32 AM, Ryan Novosielski wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 06/28/2011 12:30 PM, David Sparro wrote: >>> On 6/28/2011 11:15 AM, iharrathi@orange-ftgroup.com wrote: Hi all, I'm testing the same version of bind 9.4-ESV-R4-P1 on two server, one is a 32 bit (on which i have a redhat 32 bit) and the second a 64 bit server on which i have a redhat 64 bit. on the 32 bit i reach 7 qps but on the 64 bit i only reach 5 qps (using resperf) and also with tcpreplay. Is it normal that bind when compiled and installed on a 32 bit server have better performance than bind when compiled and installed on a 64 bit server. the only diff?rence between the two server is 64 bit vs 32 bit ( same RAM, same Disk, same NIC,...) and CPU is better on the 64 bit (2 Intel E5310 quad-core 1.6Ghz) than the 32 bit(2 Intel Xeon duad-core 2.33Ghz). Thanks. >>> >>> The 32 bit rig is faster (2.33Ghz). >> >> My understanding is that 64-bit is NOT faster in most cases, and only >> makes some things possible (addressing large amounts of memory is one >> stand-out) that are not possible with 32-bit. If bind is not going to be >> using over 4GB of RAM by itself, my understanding is that running 64-bit >> will merely add overhead. I realize that is a pretty big generalization, >> so feel free to correct me if you know better. > > I'll take it a step farther. In my experience running code in 64-bit > mode is USUALLY slightly slower than running it in 32-bit mode on the > same hardware. This is mostly because of the added data that must be > moved for 64-bit operations. It also means the 64-bit binaries are > larger, often by a significant amount. > > I recommend sticking with 32-bit systems unless you have a specific > need for 64-bit capacity. My recommendation would be use a 64Bit OS, but 32Bit applications as long as they don't need a large amount of memory. One should not install a 32Bit OS on a server today until it is a embeded device or something similar. Regards Andreas -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 902, Issue 1 ** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___
RE: bind-users Digest, Vol 902, Issue 1
Thanks for the answer, @ Andreas i made the test and i have the same performance as OS 64 bind 64. NB: when i reach the maximum throughput i still have enough free RAM, free CPU, free NIC capacity. So the limit is in Bind. What to do to reach more capacity? Tests: Test1: OS 64 bit, bind 64 bit ==> 5 qps Test2: OS 32 bit, bind 32 bit ==> 7 qps Test3: OS 64 bit, bind 32 bit ==> 5 qps Regards Issam Harrathi. Message: 7 Date: Wed, 29 Jun 2011 09:16:01 +0200 From: lst_ho...@kwsoft.de Subject: Re: better performance with 32 bit ! why? To: bind-users@lists.isc.org Message-ID: <20110629091601.30282lyntw1u4...@webmail.kwsoft.de> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Zitat von Kevin Oberman : > On Tue, Jun 28, 2011 at 7:32 AM, Ryan Novosielski wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 06/28/2011 12:30 PM, David Sparro wrote: >>> On 6/28/2011 11:15 AM, iharrathi@orange-ftgroup.com wrote: Hi all, I'm testing the same version of bind 9.4-ESV-R4-P1 on two server, one is a 32 bit (on which i have a redhat 32 bit) and the second a 64 bit server on which i have a redhat 64 bit. on the 32 bit i reach 7 qps but on the 64 bit i only reach 5 qps (using resperf) and also with tcpreplay. Is it normal that bind when compiled and installed on a 32 bit server have better performance than bind when compiled and installed on a 64 bit server. the only diff?rence between the two server is 64 bit vs 32 bit ( same RAM, same Disk, same NIC,...) and CPU is better on the 64 bit (2 Intel E5310 quad-core 1.6Ghz) than the 32 bit(2 Intel Xeon duad-core 2.33Ghz). Thanks. >>> >>> The 32 bit rig is faster (2.33Ghz). >> >> My understanding is that 64-bit is NOT faster in most cases, and only >> makes some things possible (addressing large amounts of memory is one >> stand-out) that are not possible with 32-bit. If bind is not going to be >> using over 4GB of RAM by itself, my understanding is that running 64-bit >> will merely add overhead. I realize that is a pretty big generalization, >> so feel free to correct me if you know better. > > I'll take it a step farther. In my experience running code in 64-bit > mode is USUALLY slightly slower than running it in 32-bit mode on the > same hardware. This is mostly because of the added data that must be > moved for 64-bit operations. It also means the 64-bit binaries are > larger, often by a significant amount. > > I recommend sticking with 32-bit systems unless you have a specific > need for 64-bit capacity. My recommendation would be use a 64Bit OS, but 32Bit applications as long as they don't need a large amount of memory. One should not install a 32Bit OS on a server today until it is a embeded device or something similar. Regards Andreas -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 902, Issue 1 ** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ 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: Named.conf logical blocks
On 06/28/2011 09:54 PM, Stefan Certic wrote:
I am more looking for a solution to read data with perl and convert to some
native data structure, like hash reference, or multidimenzional array, so i
can access and change data in form of: $named_conf_file->{view1}-{zoneblah} =
'somedata' and then dump it back into original format.
Ok, that didn't really come across in your email.
http://augeas.net/
...does what you want. It has a "lense" (their term for a config file
description) for ISC dhcpd, which is a very similar syntax. It should be
relatively trivial to turn out a lense for ISC bind.
Or use Config::Parser, or adapt the script I sent round (which in fact
was the reason I wrote it); tokenisation of the bind config file is
easy, and the core grammar is straightforward because everything is
;-terminated, with the form:
item = thing+ block semicolon
thing = word | quoted-string
block = { item+ }
___
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: better performance with 32 bit ! why?
Zitat von Kevin Oberman : On Tue, Jun 28, 2011 at 7:32 AM, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2011 12:30 PM, David Sparro wrote: On 6/28/2011 11:15 AM, iharrathi@orange-ftgroup.com wrote: Hi all, I'm testing the same version of bind 9.4-ESV-R4-P1 on two server, one is a 32 bit (on which i have a redhat 32 bit) and the second a 64 bit server on which i have a redhat 64 bit. on the 32 bit i reach 7 qps but on the 64 bit i only reach 5 qps (using resperf) and also with tcpreplay. Is it normal that bind when compiled and installed on a 32 bit server have better performance than bind when compiled and installed on a 64 bit server. the only différence between the two server is 64 bit vs 32 bit ( same RAM, same Disk, same NIC,...) and CPU is better on the 64 bit (2 Intel E5310 quad-core 1.6Ghz) than the 32 bit(2 Intel Xeon duad-core 2.33Ghz). Thanks. The 32 bit rig is faster (2.33Ghz). My understanding is that 64-bit is NOT faster in most cases, and only makes some things possible (addressing large amounts of memory is one stand-out) that are not possible with 32-bit. If bind is not going to be using over 4GB of RAM by itself, my understanding is that running 64-bit will merely add overhead. I realize that is a pretty big generalization, so feel free to correct me if you know better. I'll take it a step farther. In my experience running code in 64-bit mode is USUALLY slightly slower than running it in 32-bit mode on the same hardware. This is mostly because of the added data that must be moved for 64-bit operations. It also means the 64-bit binaries are larger, often by a significant amount. I recommend sticking with 32-bit systems unless you have a specific need for 64-bit capacity. My recommendation would be use a 64Bit OS, but 32Bit applications as long as they don't need a large amount of memory. One should not install a 32Bit OS on a server today until it is a embeded device or something similar. Regards Andreas ___ 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
