Recommended setup with large cache memory

Attila Nagy bra at fsn.hu
Fri Sep 9 10:13:46 UTC 2005


Brad Knowles wrote:
>>  I have made some benchmarks with and without threading and even bind
>>  9.3.1 is faster without it. Did you try to compile without threading?
>     Have you tested it on an SMP machine?  Threading is really only 
> useful if done with multiple CPUs for the program to make use of.
Yes.

BTW, I am not the only one:
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044565.html

>>  BTW, did anybody thought about having a different caching (and even
>>  authoritative) backend, for example a memcached, spreading many 
>> machines?
>     There is the DLZ-BIND stuff, but that's for authoritative services 
> and not caching.
Yes, I am aware of that, but as you say, it's a different story. And 
also the performance will be much worse, I guess.

>     You're talking about striping everything across all the back-end 
> machines, and all clients would be hurt equally if one of those back-end 
> machines were to die.
Nope. What I am talking about is dropping the current memory allocator 
out of bind and replace the store and get procedures (again, I did not 
look at the code, so if the design is not so clean, it may be harder) 
with -for example- memcached calls.
See http://www.danga.com/memcached/ for details.

You can run and use multiple memcached machines and if one fails, there 
is no problem. There is no SPF, if I am right.

>     The current BIND solution is more like mirroring, which is much more 
> resilient to failure of a single machine, especially if used in 
> combination with a high-available load-balancing switch to detect and 
> route around failures of back-end machines.
That's what we are using. But if we -say- have four machines with four 
gigs of RAM in each of them, this is simply wasting of resources.

If we could have four caches with 512 MB of RAM and four machines with 4 
gigs, I would have 16 GB of cache, which is unique to the whole cluster, 
so there is no multiple instances of the same data, and there is no such 
a problem that my nameserver of the IP 1.1.1.1 gives different answers 
for subsequent queries.

Also, if a backed server disappears, I don't care about the loss of 4 
GBs of cached RRs. What is important to maintain the working state, 
which is the case in this setup.

Of course if you have fewer machines, it doesn't really matter. But bind 
isn't so fast, so you have to drop a lot of machines for it and storing 
the same in a lot of machines without showing a consistent view to the 
customers is bad. :(

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Adopt a directory on our free software   phone @work: +361 371 3536
server! http://www.fsn.hu/?f=brick             cell.: +3630 306 6758



More information about the bind-users mailing list