Maintained by: NLnet Labs

[Unbound-users] Uneven distribution of queries between threads/processes

W.C.A. Wijngaards
Mon Feb 13 09:50:22 CET 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Attila,

On 02/12/2012 05:39 PM, Attila Nagy wrote:
> Hi,
> 
> Not a new thing, and likely it's how the OS (FreeBSD) works -if
> the listening socket is shared between threads and processes-, but
> the number of queries are very unevenly distributed between
> unbound threads/processes.
> 
> For a threaded unbound currently the QPSs are: thread0: 1.45k 
> thread1: 2.72k thread2: 3.97k
> 
> and for a multiprocess unbound: thread0: 1.16k thread1: 3.05k 
> thread2: 2.34k
> 
> Is it possible to make it more balanced on the application side?

Very interesting.  I assume you have a quadcore, or a tricore :-)

Unbound simply listens to the port 53 socket.  There is nothing else
it can do I think?  Unless there are some secret socket options that
make FreeBSD do something like load-spreading?

If you want to force this issue, you could create firewall/pf rules
that rewrite incoming packets to three other port numbers (1053, 1054,
1055) and start unbound three times on port 1053, 1054, 1055.  Make
sure you also rewrite the UDP replies back to sourceport 53.  In this
case, then, I can do something on the software side, instead of
forcing you to run 3x unbound, some sort of option that makes unbound
have every process listen to its own port number could be create.  But
this approach may be useless, perhaps the system does not do load
spreading because this queryamount (8k) is too low (it has a max of
300k?).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPOM7OAAoJEJ9vHC1+BF+NeS0QALEBWFqv9GDODRwIjqU7IPS1
d5O3UVlfrP5LRcUxUVHMkguIABo2OatcMtTT5ZQ0/VWJ1ECcTs9Zruq6U8UQptNa
DhdDyQ9p/hh9+FavRWJ1WovoG/exzKaJ8V9YwCKUAy+kZ/OOK/Q4URHjmUAtQ5wQ
whxkd/3AKj0/1UcS3IUpprRm6ZC6ndO0Zs9LHvUOhp9IoTmvUAAxcX1gAerk/QfM
HNOJkb0eAgYEWNBdnv3jugSfEQsMEMzbtCgENkFl+jaLFvXRBriKInDgPfgB/zn8
iJT0EcAw9S2kgwUT6Y8ngjEROuctBWzZLruj5YFPzEIf0U03nIWPlk1+s0GOGG9b
tpzT3oaMXRgtjET2rr3+WVO7RX2R663tLYV6tVbLmckhevR2b7gqeuC2LElS+cOw
4H6Ex+bU6CvJGf6hOnhmjss/W49YOOkfHDmr2i244Jk0QZ3Srhpq4v5pK45H/yKw
crVAMYeoUe8s1iucsaWPNU936Q7snlRIvaT5p+sBvE05B6Rty8zmN2Yzt8xP+/Z0
wmg969H3B9Ts5QG+2e7912V7QnW02FxZzGWKEyUwU86zmjQ/tfIce+i96SNT2MzU
Ag1EYmIOQyNyN5njNKeOXH9+/EkDGDPHsipxPpQm/7S9qfl+LKI5vLhqM2FnP90d
vKInI+iXrpX4IlScnnxa
=bHj5
-----END PGP SIGNATURE-----