At Thu, 22 Jan 2009 09:12:11 +0300, Dmitry Rybin <kirg...@corbina.net> wrote:
> > +50 views of zone data + memory for 100000 clients + .... > > > > You have a 32bit build which will give a maximum of 2G data. > > > > You are just trying to cram too much into too small a place. > > OK. May be you can give any recomendation? As Mark said, having 50 views, each of which contains non-negligible amount of cache, is an excessive condition. Also, since the matching view is identified by linear search for every query, it may also impact your query processing performance. So, you'd primarily consider reducing the number of views anyway. Still, I noticed cache management may not work well (even with a single view) especially when it's multi-threaded and configured with a small max-cache-size such as 16MB. (It's ironical that using a small max-cache-size could hinder cache cleaning, resulting in larger memory footprints). I'm developing a fix to this problem. Can you try the patch available at: http://www.jinmei.org/patch/bind9-lrucache.diff (should be cleanly applicable to 9.6). and let me know if it mitigates the problem? Other recommendations: - I previously suggested using a separate cache-only view and forward all recursive queries to that view. Have you tried that? If you have, didn't it work as I hoped? - BIND 9.7 will have a new option "attach-cache" exactly for such an extraordinary operational environment as yours: it allows multiple views to share a single cache to save memory. --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
