Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Claudio Jeker cje...@diehard.n-r-g.com writes: Don't forget to increase the UDP recvbuffer space. The default is somewhat small and will result in drops. At least you should invest some time to play with that value and see if it helps. I played with the net.inet.udp.recvspace sysctl option today. The maximum allowed value for it is 262144. After that things break (as in no daemons start, network is disabled and during boot I get the message ifconfig: socket: No buffer space available). I guess I am reaching some sort of kernel limit, without producing kernel panic. With the maximum value I do see udp packet drops in my tests (that increase as the test provides larger query rates) root@dmeg-dns1 ~ # netstat -s -p udp udp: 268217 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 194 with no checksum 267842 input packets hardware-checksummed 0 output packets hardware-checksummed 130 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to missing IPsec protection 64705 dropped due to full socket buffers ^ 203382 delivered 212059 datagrams output 187019 missed PCB cache Unfortunately I see no real difference in BIND's performance with the values I tested (262144, 131072). -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Stuart Henderson s...@spacehopper.org writes: On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote: root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with --enable-shared' '--enable-threads' You could try rebuilding the port without --enable-threads and see if it's any different. I rebuilt the port without threads root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe' using OpenSSL version: OpenSSL 1.0.1c 10 May 2012 using libxml2 version: 2.8.0 There was no great difference in performance. I could see in the multi-threaded BIND version CPU utilization of up to 300% (Linux showed up to 800% on the same tests). In repeating tests with resperf (to have a full cache) and giving more slack in the rampup time of the queries (resperf -r 240 -s server IP -d recorded_queries) I was able to reach around 20K queries / sec on my hardware, half the performance of Linux on the same hardware, BIND version and configuration. PF disabled. Might also test unbound. If I do, I will post the results. PS: I think I saw a slight improvement using -U 4 (provided by the port's init script) -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
On Mon, Apr 22, 2013 at 04:50:52PM +0300, Kostas Zorbadelos wrote: Stuart Henderson s...@spacehopper.org writes: On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote: root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with --enable-shared' '--enable-threads' You could try rebuilding the port without --enable-threads and see if it's any different. I rebuilt the port without threads root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe' using OpenSSL version: OpenSSL 1.0.1c 10 May 2012 using libxml2 version: 2.8.0 There was no great difference in performance. I could see in the multi-threaded BIND version CPU utilization of up to 300% (Linux showed up to 800% on the same tests). In repeating tests with resperf (to have a full cache) and giving more slack in the rampup time of the queries (resperf -r 240 -s server IP -d recorded_queries) I was able to reach around 20K queries / sec on my hardware, half the performance of Linux on the same hardware, BIND version and configuration. PF disabled. Might also test unbound. If I do, I will post the results. PS: I think I saw a slight improvement using -U 4 (provided by the port's init script) Don't forget to increase the UDP recvbuffer space. The default is somewhat small and will result in drops. At least you should invest some time to play with that value and see if it helps. -- :wq Claudio
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
I've never used BIND in this sort of instance, so I can't speak to that. I can say, however, I've run reasonably large authoritative anycast DNS setups with NSD and OpenBSD. two north american sites, 10Kqps average, with one notable 80K spike. the whole system ran practically untouched (minor BGPd and NSD patches) for two years. ymmv On Sat, Apr 20, 2013 at 3:18 PM, Stuart Henderson s...@spacehopper.orgwrote: On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote: root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--enable-threads' You could try rebuilding the port without --enable-threads and see if it's any different.
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote: root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--enable-threads' You could try rebuilding the port without --enable-threads and see if it's any different.
Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Hello all, quite a few months ago I had evaluated OpenBSD for a large scale anycast DNS resolving setup: http://marc.info/?l=openbsd-miscm=133828399728289w=2 The findings at the time (using VMs in a lab environment) was that OpenBSD failed to meet my performance requirements and the main suspicion was the lack of kernel-level thread support that could be utilized by BIND. Since then we purchased real hardware (Dell R620), with complete dmesg attached and I decided to re-evaluate OpenBSD just before the 5.3 release. # sysctl hw hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz hw.ncpu=12 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:a8089dcaa911bf20,cd0: hw.diskcount=2 hw.sensors.cpu0.temp0=73.00 degC hw.sensors.cpu1.temp0=73.00 degC hw.sensors.cpu2.temp0=73.00 degC hw.sensors.cpu3.temp0=73.00 degC hw.sensors.cpu4.temp0=73.00 degC hw.sensors.cpu5.temp0=73.00 degC hw.sensors.cpu6.temp0=73.00 degC hw.sensors.cpu7.temp0=73.00 degC hw.sensors.cpu8.temp0=73.00 degC hw.sensors.cpu9.temp0=73.00 degC hw.sensors.cpu10.temp0=73.00 degC hw.sensors.cpu11.temp0=73.00 degC hw.sensors.mfi0.drive0=online (sd0), OK hw.cpuspeed=2800 hw.vendor=Dell Inc. hw.product=PowerEdge R620 hw.serialno=4J89G5J hw.uuid=44454c4c-4a00-1038-8039-b4c04f47354a hw.physmem=17082220544 hw.usermem=17082163200 hw.ncpufound=12 hw.allowpowerdown=1 I used the isc bind 9.9 port generously provided by Stuart using default compile options on a snapshot: root@dmeg-dns1 ~ # uname -a OpenBSD dmeg-dns1.otenet.gr 5.3 GENERIC.MP#40 amd64 root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--enable-threads' '--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe' using OpenSSL version: OpenSSL 1.0.1c 10 May 2012 using libxml2 version: 2.8.0 And using the following shell environment root@dmeg-dns1 /var/named # ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 8388608 stack(kbytes)8192 lockedmem(kbytes)5409752 memory(kbytes) 16227120 nofiles(descriptors) 7030 processes1310 I started bind as root@dmeg-dns1 ~ # /usr/local/sbin/named -t /var/named/ The tests were conducted using two identical machines running CentOS 6.4 and the OpenBSD snapshot reffered to above. BIND configuration was identical, a validating caching resolver setup. PF was disabled on OpenBSD, while I had an IPtables ruleset on Linux. Using Nominum's resperf (like in the last evaluation) I could achieve ~40K queries / sec on Linux (after 3 times resperf running with options -s server IP -r 120 -d ~/recorded_queries) while only ~9K queries / sec on OpenBSD (this is less than the current load on our nameservers). Is there anything I could be missing or a configuration I should try, before giving up? The thing is that the performance on OpenBSD was worse than the last time I checked using a release without threading support!!! Any suggestions are highly welcome. -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\ [demime 1.01d removed an attachment of type application/octet-stream]
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Give up. For the record. I had BIND on Ubuntu 12.04 on Dell R610. It constantly segfaulted for yet unknown reason (lazy to debug). This machine was overloaded with resources. However, not much of load as yours, but I'v tired of this and put all zones to R620 with OpenBSD 5.3. So far not a sound of any slow queries because of segfaulted BIND-slave. //mxb On 19 apr 2013, at 16:36, Kostas Zorbadelos kzo...@otenet.gr wrote: Hello all, quite a few months ago I had evaluated OpenBSD for a large scale anycast DNS resolving setup: http://marc.info/?l=openbsd-miscm=133828399728289w=2 The findings at the time (using VMs in a lab environment) was that OpenBSD failed to meet my performance requirements and the main suspicion was the lack of kernel-level thread support that could be utilized by BIND. Since then we purchased real hardware (Dell R620), with complete dmesg attached and I decided to re-evaluate OpenBSD just before the 5.3 release. # sysctl hw hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz hw.ncpu=12 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:a8089dcaa911bf20,cd0: hw.diskcount=2 hw.sensors.cpu0.temp0=73.00 degC hw.sensors.cpu1.temp0=73.00 degC hw.sensors.cpu2.temp0=73.00 degC hw.sensors.cpu3.temp0=73.00 degC hw.sensors.cpu4.temp0=73.00 degC hw.sensors.cpu5.temp0=73.00 degC hw.sensors.cpu6.temp0=73.00 degC hw.sensors.cpu7.temp0=73.00 degC hw.sensors.cpu8.temp0=73.00 degC hw.sensors.cpu9.temp0=73.00 degC hw.sensors.cpu10.temp0=73.00 degC hw.sensors.cpu11.temp0=73.00 degC hw.sensors.mfi0.drive0=online (sd0), OK hw.cpuspeed=2800 hw.vendor=Dell Inc. hw.product=PowerEdge R620 hw.serialno=4J89G5J hw.uuid=44454c4c-4a00-1038-8039-b4c04f47354a hw.physmem=17082220544 hw.usermem=17082163200 hw.ncpufound=12 hw.allowpowerdown=1 I used the isc bind 9.9 port generously provided by Stuart using default compile options on a snapshot: root@dmeg-dns1 ~ # uname -a OpenBSD dmeg-dns1.otenet.gr 5.3 GENERIC.MP#40 amd64 root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with '--enable-shared' '--enable-threads' '--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe' using OpenSSL version: OpenSSL 1.0.1c 10 May 2012 using libxml2 version: 2.8.0 And using the following shell environment root@dmeg-dns1 /var/named # ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 8388608 stack(kbytes)8192 lockedmem(kbytes)5409752 memory(kbytes) 16227120 nofiles(descriptors) 7030 processes1310 I started bind as root@dmeg-dns1 ~ # /usr/local/sbin/named -t /var/named/ The tests were conducted using two identical machines running CentOS 6.4 and the OpenBSD snapshot reffered to above. BIND configuration was identical, a validating caching resolver setup. PF was disabled on OpenBSD, while I had an IPtables ruleset on Linux. Using Nominum's resperf (like in the last evaluation) I could achieve ~40K queries / sec on Linux (after 3 times resperf running with options -s server IP -r 120 -d ~/recorded_queries) while only ~9K queries / sec on OpenBSD (this is less than the current load on our nameservers). Is there anything I could be missing or a configuration I should try, before giving up? The thing is that the performance on OpenBSD was worse than the last time I checked using a release without threading support!!! Any suggestions are highly welcome. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\ [demime 1.01d removed an attachment of type application/octet-stream]
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Kostas Zorbadelos kzo...@otenet.gr writes: Here is the missing dmesg: OpenBSD 5.3-current (GENERIC.MP) #40: Tue Mar 26 10:25:59 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17082220544 (16290MB) avail mem = 16619790336 (15849MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (95 entries) bios0: vendor Dell Inc. version 1.2.6 date 05/10/2012 bios0: Dell Inc. PowerEdge R620 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT EINJ TCPA SRAT SSDT acpi0: wakeup devices PCI0(S5) PCI1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.39 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu5: 256KB 64b/line 8-way L2 cache cpu6 at mainbus0: apid 1 (application processor) cpu6: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu6: 256KB 64b/line 8-way L2 cache cpu7 at mainbus0: apid 3 (application processor) cpu7: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.01 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu7: 256KB 64b/line 8-way L2 cache cpu8 at mainbus0: apid 5 (application processor) cpu8: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu8: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu8: 256KB 64b/line 8-way L2 cache cpu9 at mainbus0: apid 7 (application processor) cpu9: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz cpu9: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu9: 256KB 64b/line 8-way L2 cache cpu10 at
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
From mine point of view, OpenBSD is a stable OS (even some aged snapshots). I don't put any performance pressure on it. I just want services to be STABLE. If I want STABLE, I replace Linux or any other with OpenBSD. //mxb On 19 apr 2013, at 20:22, Kostas Zorbadelos kzo...@otenet.gr wrote: mxb m...@alumni.chalmers.se writes: Give up. For the record. I had BIND on Ubuntu 12.04 on Dell R610. It constantly segfaulted for yet unknown reason (lazy to debug). This machine was overloaded with resources. However, not much of load as yours, but I'v tired of this and put all zones to R620 with OpenBSD 5.3. So far not a sound of any slow queries because of segfaulted BIND-slave. Never had an issue with custom compiled latest BIND version on CentOS 5 or 6. Although I proceed with my project on CentOS Linux, I want to keep an eye to OpenBSD developments. I guess all the threading work is happening to give a performance boost and not the other way round, correct? Either way I am willing to test. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
mxb m...@alumni.chalmers.se writes: From mine point of view, OpenBSD is a stable OS (even some aged snapshots). I don't put any performance pressure on it. I just want services to be STABLE. I really can't speak for the developers, but achieving less that 1/4 of the performance of Linux for DNS and mainly, achieving LESS with thread support than before threads sound like an issue to me. Perhaps it is just the beginning of a lot of work than lies ahead after the thread introduction. If I want STABLE, I replace Linux or any other with OpenBSD. I don't see why stable and decently performant should be contradictory. Regards //mxb -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot
Well, I actually told you to Give up in my first mail :) So do it. In your env. in is(probably) better to run Linux. Do it. I just tell you MINE point of view. If your don't want to hear it - I'll shut up. P.S. std. answer to ANY on this list - You ever contribute with code or you wait for your turn (or you solve it other way by yourself). If you want it right - you have to do it yourself. P.S.S. No offense. It's just how it works in real world - you DO it yourself or you don't. //mxb On 19 apr 2013, at 21:57, Kostas Zorbadelos kzo...@otenet.gr wrote: mxb m...@alumni.chalmers.se writes: From mine point of view, OpenBSD is a stable OS (even some aged snapshots). I don't put any performance pressure on it. I just want services to be STABLE. I really can't speak for the developers, but achieving less that 1/4 of the performance of Linux for DNS and mainly, achieving LESS with thread support than before threads sound like an issue to me. Perhaps it is just the beginning of a lot of work than lies ahead after the thread introduction. If I want STABLE, I replace Linux or any other with OpenBSD. I don't see why stable and decently performant should be contradictory. Regards //mxb -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
