On Wed, May 22, 2019 at 11:39:04PM +0200, Ict Security wrote: > Dear Klaus, > > >>btw - how high is the "extremely load"? > Without old DLZ module, Bind 9.12 scales to thousands and thousands of > queries. > If i include old DLZ module, with postgres, over about 1000 Qps Bind > start to slow down visibly, > > Do you think the old DLZ-Postgreqsl module might the bottleneck? > Any possible replacement, continuing using Postgresql (i made an > implementation to activate some custom filtering with a database).
It might be. The dns_db API (which DLZ is an implementation of) is a synchronous API. When a named thread asks dns_db to find an answer for it, it will block until the dns_db API returns. This has almost no effect when using the in-memory zones/cache which is typical, but when you start using a database backend within dns_db which can block waiting for an answer, this can tie up all the worker threads, depending on the rate of response from the database. This would also cause queries to queue up on the listening socket. Use pstack <pid-of-the-named-process> when it appears to be stuck to see if the threads are stuck within the DLZ implementation. If that is the case, perhaps you can try increasing the number of worker threads greatly (named -n ###) to see if that helps mitigating the issue. In answer to your other question about why a query to another alias interface appears to work, it is a different queue that by your description has nothing waiting in it. Mukund _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users