Zack Allen [Fri, 20 Dec 2013 21:28:21 +0000 (16:28 -0500)]
Updated global PDNS log table with DROP and PASS values to return on the stack for passthrough. This allows for users issue a dontanswer type to drop and not process any unwanted queries. Updated the example script to reflect changes. Updated the pdns.xml to reflect changes
bert hubert [Mon, 16 Dec 2013 12:19:52 +0000 (13:19 +0100)]
ok, so it turns out that poll, select and a few other system calls can return EINTR when we receive and interrupt, and we need to manually restart. man 7 signal makes for good reading on this case, as does http://blog.reverberate.org/2011/04/eintr-and-pc-loser-ing-is-better-case.html
Mark Zealey [Sat, 14 Dec 2013 21:38:09 +0000 (23:38 +0200)]
Remove AnswerData.created time field as it doesn't seem to be referenced anywhere and the time() call seems to take about 1-2% of process time under high load.
Mark Zealey [Fri, 13 Dec 2013 20:39:47 +0000 (22:39 +0200)]
On testing with large numbers of unknown domains the send-root-referral
argument query amounted to quite a high proportion of CPU time. This will cache
it to reduce this overhead as is already done with a number of variables.
Mark Zealey [Mon, 2 Dec 2013 09:19:24 +0000 (11:19 +0200)]
fixes PowerDNS/pdns#692
For the second time when writing a backend I forgot that an ANY query needs to return any SOA data as well. This is because we store our SOA's separately from our other DNS data in order to optimize zone lookups. According to Habbie MyDNS backend has the same bug. The attached patch basically forces an SOA to be included which is actually much more optimal than anything I can do in my backends as I don't have easy access to the knowledge of:
* sd data structure;
* is this query also an SOA
meaning that if I answer it in the backend I have to do a number of additional lookups for information that is already available in the PacketHandler. Additionally, I notice that you are basically doing all the SOA setup anyway if there is anything looking like an SOA entry. So, all this patch does is strip out any SOA entries and then insert one if there should be. This seems to me to both potentially simplify backend code and fix up any user errors more accurately than the current code does.
Mark Zealey [Mon, 2 Dec 2013 09:07:00 +0000 (11:07 +0200)]
fixes PowerDNS/pdns/#661
I was doing some performance testing on our 32-way servers and discovered that in the simple case where the test program returns the data straight away, about 80% of the time was being spent in the kernel in a spinlock. I've been debugging this looking at the coprocess code and discovered that this is due to the following line in coprocess.cc:
setbuf(d_fp,0); // no buffering please, confuses select
If this is removed, performance in my particular test case goes from 2000qps with powerdns running at about 2000% cpu to 10000qps with powerdns using about 300% cpu.
Obviously the comment implies that this is not a permanent solution, I guess if the timeout is specified as 0 then the select code won't be executed and so you can disable the setbuf easily enough. However perhaps if the timeout is wanted you could set an alarm() rather than using select?
Mark Zealey [Mon, 2 Dec 2013 08:42:40 +0000 (10:42 +0200)]
fixes PowerDNS/pdns/657
I noticed this as a result of the changes in 3.2 whereby each receiver gets its own distributor - whenever the dynhandler calls ->getBackend() it will only find the one in its' current thread, so reload won't propergate to backends within other threads.
However, I suspect this condition has always been around as a race - if I have multiple distributors and I call reload; one thread is issuing reloads while all the other backend threads are currently executing (potentially). I guess if you call reload in previous versions on a highly loaded server with multiple backends you could probably get it to crash.
The attached patch changes it so that each backend has a variable which is changed to signal that a reload or rediscover has been requested. When processing gets to an appropriate point ie before it next queries the backend database, such an operation will be run. Note that it is not run in ::get as we don't want a backend to be reloaded between performing a lookup and getting the records.
This patch means that reload/reinitialize are not done straight away as in previous versions, but on a moderately loaded server this should not be a problem as they will be performed the next time a backend is called.
projects / pdns / log