Re: [PATCH] dnscache: merge similar outgoing udp packets

Krzysztof Gajdemski <[email protected]>
Newsgroups gmane.network.djbdns
Organization Dragon Globulka Z
Message-ID <[email protected]>
21.04.2009, 16:10:41, Jeff King wrote:
> On Thu, Apr 16, 2009 at 05:26:40PM -0500, Mark Johnson wrote:
> 
> > > This patch is only lightly tested. Use on production servers at your own
> > > risk (and please report to the list if you have success using it).
> > 
> > This will be going into the much delayed zinq-djbdns-0.06.
> Thanks. The list has been silent on success reports, so perhaps nobody
> is actually using it. I've been running it for a few weeks now without
> incident, but only on a lightly loaded server (and only on dnscache --
> the changes shouldn't affect other programs, but I haven't tested it
> extensively).

I've just tested Your patch in rather loaded dnscache cluster. Patched
dnscache was installed on only one server within the cluster so
performance between patched and unpatched version could be easily
compared. During a period of testing (about one hour) I had no visible
name resolving problems. Query merging engine also worked just fine.
Unfortunately, there was a serious performance issue. 

Hardware and software configuration of each machine was identical (quite
old 2 x Xeon 3GHz IBM x336 server), on each host two instances of
dnscache were run. During the tests single dnscache instance processed
above 1000 queries per second (a rather low value for my system - it
was early morning). Average usage of each CPU on unpatched servers was 
about 30%, but on the patched server with MERGEQUERIES variable set, it
raised to 90% - 95% (the process consuming almost all CPU power was of
course dnscache). After removing the MERGEQUERIES variable, CPU usage
lowered to a normal level (ca. 30%), so I think the problem lays
somewhere in query merging code.

Your patch was tested against lightly modified dnscache. The
modifications include:

- SOA caching patch;
- Large CACHESIZE patch. In fact, CACHESIZE was set to 2000000000 for
  each dnscache instance (but no swapping, memory shortage or IO issues).

All above was tested under Debian GNU/Linux with 2.4 kernel on the i386
architecture. If you have any additional questions, don't hesitate to
ask. 

Regards,

      k.

PS. Thanks for all excellent work done to make dnscache less vulnerable.
-- 
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: 3C38979D
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.