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 <[email protected]> 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-misc&m=133828399728289&w=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 > processes 1310 > > 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]
