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 20000 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) CPU 5140 @ 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 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
