Why are unbound-control local_zone_remove/local_zone/local_data so incredibly slow ?
Ralph Dolmans
ralph at nlnetlabs.nl
Wed Nov 30 13:36:30 UTC 2016
Hi,
Unbound-control sets up a TLS connection for every command. Setting up
30k TLS connections one after another does take some time.
If your unbound daemon and unbound-control are on the same machine you
could try to communicate over a secured local socket and disable
control-use-cert. This might speed it up a little.
I just added some code to Unbound to bulk add and remove local-zones and
local-data, by reading input from stdin. This gives the possibility to
do the update over a single connection using local_zones,
local_zones_remove, local_datas and local_datas_remove. This code will
be in the next Unbound release.
Regards,
-- Ralph
On 28-11-16 13:18, Tim Smith via Unbound-users wrote:
> Hello list,
>
> I'm running Unbound 1.5.9 on OpenBSD 6.
>
> I have the need to periodically add certain local data to unbound as
> part of a dynamic security block list (i.e. redirect to null). These
> lists can be 30k+ items in length.
>
> Originally, I had this scripted as follows :
> - Get and parse data into unbound config format
> - Reload unbound
>
> Obviously the problem with that approach is that reloading unbound
> causes cache to be flushed .... which is not cool. However on the
> plus side the script runs super-quick as its just a config reload !
>
> So I looked at my options and came up with a second script :
> - Get and parse data into two groups : remove and add
> - On "remove" set run unbound-control local_zone_remove
> - On "add" set run unbound-control local_zone and unbound-control local_data
>
> The problem is its taking forever to process that because calls to
> unbound-control are so slow ! e.g. its been well over an hour now and
> it *still* hasn't finished processing 30k items. The server is not
> slow, the server is not heavily loaded, and my script is simple ....
> the problem is very much the slowness of the calls to unbound-control.
>
> Help !!
>
> Thanks
>
> Tim
>
More information about the Unbound-users
mailing list