<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Redis (nor any other nosql database) doesn’t really have the properties we need for finding closest enclosers, doing partial matches nor really the performance.<div><br></div><div>Ondrej <br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>--</div>Ondřej Surý — ISC (He/Him)<div><br></div><div>My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div><div dir="ltr"><br><blockquote type="cite">On 2. 7. 2025, at 9:41, Carlos Horowicz via bind-users <bind-users@lists.isc.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>
</p>
<blockquote style="margin: 0.0px 0.0px 0.0px 15.0px; font: 14.0px '.AppleSystemUIFont'; color: #0e0e0e">
<pre wrap="" class="moz-quote-pre">Ondřej</pre>
<br>
By the way, have you ever considered using Redis as an in-memory
cache database? I’ve been thinking about offloading some of the
TTL expiry and cache management to Redis.</blockquote>
<blockquote style="margin: 0.0px 0.0px 0.0px 15.0px; font: 14.0px '.AppleSystemUIFont'; color: #0e0e0e; min-height: 17.2px"><br>
</blockquote>
<blockquote style="margin: 0.0px 0.0px 0.0px 15.0px; font: 14.0px '.AppleSystemUIFont'; color: #0e0e0e">In
some customer environments, the query volume is extremely high —
we’re using Mellanox CX-6 25G interfaces, which already handle a
lot of offloading and fair IRQ distribution at the NIC level — so
I wonder if you ever ran into performance limitations with Redis
under similar loads, or decided against it for architectural
reasons.<br>
<br>
Just curious....<br>
</blockquote>
<p>Thank you</p>
<p>Carlos Horowicz<br>
Planisys<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 02/07/2025 06:53, Ondřej Surý wrote:<br>
</div>
<blockquote type="cite" cite="mid:14EFF62D-9F79-4173-84C8-FD2B21E62C74@isc.org">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On 2. 7. 2025, at 0:14, OwN-3m-All <a class="moz-txt-link-rfc2396E" href="mailto:own3mall@gmail.com"><own3mall@gmail.com></a> wrote:
I wonder if other memory issues users are complaining about are related.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">I don’t know. You were the first one to actually provided a reproducer and a usable test case. Despite your exaggeration about “countless” reports there were not that many of them actually.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">How many zones can a bind instance handle realistically?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">Internally, we are testing BIND 9 with 1M small zones and it works just fine.
What happened was that 9.20 introduced a new database backend called QP that replaced venerable custom red-black tree implementation we had. The side effect of that was 12K memory chunk overhead per zone. Under normal conditions, this would not manifest as that 12K would get filled with the zone data, but in the case of almost empty zone, the memory chunk would be mostly empty and it just blew up the memory requirements.
BIND 9.22 will contain an optimization that gradually increases the memory chunk size and that allows “auto tuning” for both small zones, large zones and the cache.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
</pre>
</blockquote>
<span>-- </span><br><span>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span>bind-users@lists.isc.org</span><br><span>https://lists.isc.org/mailman/listinfo/bind-users</span><br></div></blockquote></div></body></html>