Why are unbound-control local_zone_remove/local_zone/local_data so incredibly slow ?
r.a.n.d.o.m.d.e.v.4+unbound at gmail.com
Wed Nov 30 14:25:22 UTC 2016
Hmm... bad news ...have just looked into it and OpenBSD default config is :
So guess I'll have to live with it until the next version.....
On 30 November 2016 at 13:36, Ralph Dolmans via Unbound-users
<unbound-users at unbound.net> wrote:
> 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.
> -- 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 !!
More information about the Unbound-users