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]

Reply via email to