Disable cache in bind 9.6
Dmitry Rybin
How to disable cache in bind-9.6? ttl=0 - bad idea.
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Matus UHLAR - fantomas
> How to disable cache in bind-9.6? ttl=0 - bad idea.
if you know that setting TTL to 0 is a bad idea, why do yuo think that
disabling a cache in BIND is not a bad idea?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Dmitry Rybin
> On 20.01.09 12:49, Dmitry Rybin wrote:
>> How to disable cache in bind-9.6? ttl=0 - bad idea.
>
> if you know that setting TTL to 0 is a bad idea, why do yuo think that
> disabling a cache in BIND is not a bad idea?
>
Because under high load cache grows to maximum system size and stop
responding to queues. This is known problem.
Matus UHLAR - fantomas
> >> How to disable cache in bind-9.6? ttl=0 - bad idea.
> Matus UHLAR - fantomas wrote:
> > if you know that setting TTL to 0 is a bad idea, why do yuo think that
> > disabling a cache in BIND is not a bad idea?
On 20.01.09 18:39, Dmitry Rybin wrote:
> Because under high load cache grows to maximum system size and stop
> responding to queues. This is known problem.
Did you set up maximum cache size to a sane value?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Enter any 12-digit prime number to continue.
Alan Clegg
--===============3703644450656641216==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigE15C11F99F06B4E586B5EA6B"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE15C11F99F06B4E586B5EA6B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Dmitry Rybin wrote:
> Matus UHLAR - fantomas wrote:
>> On 20.01.09 12:49, Dmitry Rybin wrote:
>>> How to disable cache in bind-9.6? ttl=3D0 - bad idea.
>> if you know that setting TTL to 0 is a bad idea, why do yuo think that=
>> disabling a cache in BIND is not a bad idea?
>>
>=20
> Because under high load cache grows to maximum system size and stop
> responding to queues. This is known problem.
This is NOT a "known problem" in 9.6. Please provide your configuration
and logs that show the issue that you are having.
AlanC
--------------enigE15C11F99F06B4E586B5EA6B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkl19LkACgkQcKpYUrUDCYeZcQCcDThIeJsbxcOUUHY3BMDDCJAP
xHIAnjq97+FShLc0hc8YYAZPAnJfNUQz
=12lE
-----END PGP SIGNATURE-----
--------------enigE15C11F99F06B4E586B5EA6B--
--===============3703644450656641216==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--===============3703644450656641216==--
John Wobus
nameserver is to provide your authoritative zone data and you
have a different nameserver to handle your site's general
DNS queries.
TTL settings are part of authoritative zone data, which is
completely independent of whether you disable caching in the
nameserver.
On Jan 20, 2009, at 4:49 AM, Dmitry Rybin wrote:
> Hello!
>
> How to disable cache in bind-9.6? ttl=0 - bad idea.
Matus UHLAR - fantomas
> >How to disable cache in bind-9.6? ttl=0 - bad idea.
On 20.01.09 14:44, John Wobus wrote:
> Disabling the cache makes sense if the purpose of your
> nameserver is to provide your authoritative zone data and you
> have a different nameserver to handle your site's general
> DNS queries.
in such case it's much better to disable recursion and not use such server
for resolution, unless it's a MUST (e.g. firewalls).
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.
Dmitry Rybin
> Dmitry Rybin wrote:
>> Matus UHLAR - fantomas wrote:
>>>> How to disable cache in bind-9.6? ttl=0 - bad idea.
>>>
>> responding to queues. This is known problem.
>
> This is NOT a "known problem" in 9.6. Please provide your configuration
> and logs that show the issue that you are having.
>
> AlanC
>
this is known problem of all bind's. Bind grows up to 2Gb, become slowly
answer to queries and can't restart, only kill -9. FreeBSD 5.x....7.1,
Linux 2.6.
============
options {
directory "/etc/namedb";
max-cache-size 16M;
max-cache-ttl 3600;
max-ncache-ttl 1800;
cleaning-interval 10;
transfers-in 1000;
transfers-out 1000;
transfers-per-ns 100;
minimal-responses yes;
allow-recursion {
xxx.xxx.xxx.xxx;
};
recursive-clients 10000;
clients-per-query 80;
max-clients-per-query 100 ;
view "world" {
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
view "view0"{
max-cache-size 16M;
match-clients {
XXX.XXX.XXX.XXX;
};
include "net-views/view0.conf";
};
[... skip 48 views ...]
view "view50"{
max-cache-size 8M;
match-clients {
XXX.XXX.XXX.XXX;
};
include "net-views/view50.conf";
};
Matus UHLAR - fantomas
> >>>> How to disable cache in bind-9.6? ttl=0 - bad idea.
> >> Matus UHLAR - fantomas wrote:
> >>> if you know that setting TTL to 0 is a bad idea, why do yuo think that
> >>> disabling a cache in BIND is not a bad idea?
> > Dmitry Rybin wrote:
> >> Because under high load cache grows to maximum system size and stop
> >> responding to queues. This is known problem.
> Alan Clegg wrote:
> > This is NOT a "known problem" in 9.6. Please provide your configuration
> > and logs that show the issue that you are having.
On 21.01.09 12:10, Dmitry Rybin wrote:
> this is known problem of all bind's. Bind grows up to 2Gb, become slowly
> answer to queries and can't restart, only kill -9. FreeBSD 5.x....7.1,
> Linux 2.6.
This is _NOT_ a problem of BIND. This is a problem of its admin who can't
read the docs and set up max-cache-size, which does exactly what is needed
in this case.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
Dmitry Rybin
>
> This is _NOT_ a problem of BIND. This is a problem of its admin who can't
> read the docs and set up max-cache-size, which does exactly what is needed
> in this case.
>
Hmm... And why bind allocate all system memory, if max-cache-size 16M?
And views... 50 views. 16*50=800M. Only 800M, this is not 3..4GB of
system memory.
Mark Andrews
In message <49773369...@corbina.net>, Dmitry Rybin writes:
> Matus UHLAR - fantomas wrote:
>
> >
> > This is _NOT_ a problem of BIND. This is a problem of its admin who can't
> > read the docs and set up max-cache-size, which does exactly what is needed
> > in this case.
> >
>
> Hmm... And why bind allocate all system memory, if max-cache-size 16M?
> And views... 50 views. 16*50=800M. Only 800M, this is not 3..4GB of
> system memory.
+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.
Mark
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Dmitry Rybin
>>>
>> Hmm... And why bind allocate all system memory, if max-cache-size 16M?
>> And views... 50 views. 16*50=800M. Only 800M, this is not 3..4GB of
>> system memory.
>
> +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?
file /usr/local/sbin/named
/usr/local/sbin/named: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), for FreeBSD 7.1 (701100), dynamically linked (uses shared
libs), FreeBSD-style, stripped
Matus UHLAR - fantomas
> > This is _NOT_ a problem of BIND. This is a problem of its admin who can't
> > read the docs and set up max-cache-size, which does exactly what is needed
> > in this case.
On 21.01.09 17:38, Dmitry Rybin wrote:
> Hmm... And why bind allocate all system memory, if max-cache-size 16M?
> And views... 50 views. 16*50=800M. Only 800M, this is not 3..4GB of
> system memory.
lower it down to e.g. 4-8MB to see if it helps a bit. But I'd think if 50
views is really needed here... and if you have 800 MB of cache and 4GB of
used memory, I'd say that size of the cache is not the real problem
btw is the max-cache-size really per-view?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.
Stefan Schmidt
> view "view0"{
> max-cache-size 16M;
> match-clients {
> XXX.XXX.XXX.XXX;
> };
> include "net-views/view0.conf";
> };
>
> [... skip 48 views ...]
>
> view "view50"{
> max-cache-size 8M;
> match-clients {
> XXX.XXX.XXX.XXX;
> };
> include "net-views/view50.conf";
> };
The way i read this you are using one view for each of the different
client IPs you have. Do you really need all of those or are you just
trying to have an internal and an external view for a range of clients?
The match-clients statement takes a list of IPs, CIDR ranges or ACLs.
Stefan
--
printk("%s: huh ? Who issued this format command ?\n")
linux-2.6.6/drivers/block/ps2esdi.c
Stefan Schmidt
dirty solution that might just be it for you:
Keep running the views on your fontend nameserver but forward all
recursive queries to another recursive server via the "forward only;"
statement. IIRC that should cause BIND not to cache on the frontend
server.
Stefan
--
printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
linux-2.4.8/arch/sparc64/kernel/smp.c
JINMEI Tatuya / 神明達哉
Dmitry Rybin <kir...@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.
Dmitry Rybin
5piO6YGU5ZOJINC/0LjRiNC10YI6Cj4gaHR0cDovL3d3dy5qaW5tZWkub3JnL3BhdGNoL2JpbmQ5
LWxydWNhY2hlLmRpZmYKPiAoc2hvdWxkIGJlIGNsZWFubHkgYXBwbGljYWJsZSB0byA5LjYpLgo+
IGFuZCBsZXQgbWUga25vdyBpZiBpdCBtaXRpZ2F0ZXMgdGhlIHByb2JsZW0/Cj4gCgpPaCwgZ3Jl
YXQgd29yay4gSSdsbCB0cnkgdG9tb3Jyb3cuCgo+IE90aGVyIHJlY29tbWVuZGF0aW9uczoKPiAt
IEkgcHJldmlvdXNseSBzdWdnZXN0ZWQgdXNpbmcgYSBzZXBhcmF0ZSBjYWNoZS1vbmx5IHZpZXcg
YW5kIGZvcndhcmQKPiAgIGFsbCByZWN1cnNpdmUgcXVlcmllcyB0byB0aGF0IHZpZXcuICBIYXZl
IHlvdSB0cmllZCB0aGF0PyAgSWYgeW91Cj4gICBoYXZlLCBkaWRuJ3QgaXQgd29yayBhcyBJIGhv
cGVkPwoKWWVzLCBJIHRyeSBpdC4gQnV0IEkgY2FuJ3Qgc2V0IHR0bCB0byAwLiBJdCBkaWRuJ3Qg
d29yay4gUmVjdXJzaXZlIHF1ZXJ5CmZhaWxzLCBhbmQgYXV0aG9yaXRhdGl2ZSBxdWVyeSBiYWNr
IHRvIGNsaWVudHMgd2l0aCB0dGwgMCAgOigKCkkgaW5jcmVhc2UgbWVtb3J5IG9uIHNlcnZlcnMg
MnggUVVBRCBDT1JFIFhFT04gdXAgdG8gMTJHYi4KICBQSUQgVVNFUk5BTUUgICAgICAgVEhSIFBS
SSBOSUNFICAgU0laRSAgICBSRVMgU1RBVEUgIEMgICBUSU1FICAgV0NQVQpDT01NQU5ECjM4NjM0
IGJpbmQgICAgICAgICAgICAxMSAgIDQgICAgMCAgMzAwM00gIDI5NTJNIFJVTiAgICAyIDE1OToy
OCA0Ni40NCUKbmFtZWQKCn41MCB2aWV3cywgCm1heC1jYWNoZS1zaXplIGZvciBtb3N0IHZpZXdz
IDY0TTsKYmluZCB1cHRpbWUgKGFmdGVyIGtlcm5lbDogcGlkIDY2NyAobmFtZWQpLCB1aWQgNTM6
IGV4aXRlZCBvbiBzaWduYWwgMTEpCi0gMiBkYXlzIGFuZCA2IGhvdXJzLgoKCiBidWlsdCB3aXRo
ICctLWxvY2Fsc3RhdGVkaXI9L3ZhcicgJy0tZGlzYWJsZS1saW51eC1jYXBzJwonLS13aXRoLXJh
bmRvbWRldj0vZGV2L3JhbmRvbScgJy0tZAppc2FibGUtb3BlbnNzbC12ZXJzaW9uLWNoZWNrJyAn
LS13aXRob3V0LW9wZW5zc2wnCictLXdpdGgtbGlieG1sMj0vdXNyL2xvY2FsJyAnLS13aXRob3V0
LWlkbicgJy0tZW5hYmxlLWxhcmdlZmlsZScKJy0tZW5hYmxlLXRocmVhZHMnICctLXByZWZpeD0v
dXNyL2xvY2FsJyAnCi0tbWFuZGlyPS91c3IvbG9jYWwvbWFuJyAnLS1pbmZvZGlyPS91c3IvbG9j
YWwvaW5mby8nCictLWJ1aWxkPXg4Nl82NC1wb3J0YmxkLWZyZWVic2Q3LjEnCididWlsZF9hbGlh
cz14ODZfNjQtcG9ydGJsZC1mcmVlYnNkNy4xJyAnQ0M9Y2MnICdDRkxBR1M9LU8yIC1mbm8tc3QK
cmljdC1hbGlhc2luZyAtcGlwZScgJ0xERkxBR1M9IC1ycGF0aD0vdXNyL2xpYjovdXNyL2xvY2Fs
L2xpYicgJ0NYWD1jKysnCidDWFhGTEFHUz0tTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUn
CgpybmRjIHN0YXR1czoKdmVyc2lvbjogOS42LjAtUDEKQ1BVcyBmb3VuZDogOAp3b3JrZXIgdGhy
ZWFkczogOAoKT24gYW5vdGhlciBzZXJ2ZXIgaW4gc2FtZSBjb25maWd1cmF0aW9uIGJpbmQgd29y
a3MgMiBkYXlzIGFuZCBkaWUKd2l0aG91dCBjb3JlICBrZXJuZWw6IHBpZCA2ODIgKG5hbWVkKSwg
dWlkIDUzOiBleGl0ZWQgb24gc2lnbmFsIDExCgpNYXggbWVtb3J5IHBlciBwcm9jZXNzIC0gMTJH
Qi4gTWF5IGJlIEZyZWVCU0QgeDY0IGNhbid0IHdvcmsgbW9yZSB0aGVuIFgKR2IgcGVyIHByb2Nl
c3M/CiMgY2F0IC9ib290L2xvYWRlci5jb25mIAprZXJuLm1heGRzaXo9IjE3MTc5ODY5MTg0IiAg
ICAgICAjIDE2Z2IKa2Vybi5kZmxkc2l6PSIxNzE3OTg2OTE4NCIgICAgICAgIyAxNmdiCmtlcm4u
bWF4c3Npej0iMTM0MjE3NzI4IiAgICAgICAgIyAxMjhNQgoKCj4gLSBCSU5EIDkuNyB3aWxsIGhh
dmUgYSBuZXcgb3B0aW9uICJhdHRhY2gtY2FjaGUiIGV4YWN0bHkgZm9yIHN1Y2ggYW4KPiAgIGV4
dHJhb3JkaW5hcnkgb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQgYXMgeW91cnM6IGl0IGFsbG93cyBt
dWx0aXBsZQo+ICAgdmlld3MgdG8gc2hhcmUgYSBzaW5nbGUgY2FjaGUgdG8gc2F2ZSBtZW1vcnku
CgpJJ2xsIHRyeSB0byB0ZXN0IDkuNyBvbiBvbmUgb2YgdGhlIGhlYXZ5IGxvYWQgc2VydmVycyBh
bmQgcG9zdCByZXN1bHRzCnRvIHlvdS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCmJpbmQtdXNlcnMgbWFpbGluZyBsaXN0CmJpbmQtdXNlcnNAbGlzdHMu
aXNjLm9yZwpodHRwczovL2xpc3RzLmlzYy5vcmcvbWFpbG1hbi9saXN0aW5mby9iaW5kLXVzZXJz
Matus UHLAR - fantomas
pZ7mmI7pgZTlk4kg0L/QuNGI0LXRgjoKPiA+IGh0dHA6Ly93d3cuamlubWVpLm9yZy9wYXRjaC9i
aW5kOS1scnVjYWNoZS5kaWZmCj4gPiAoc2hvdWxkIGJlIGNsZWFubHkgYXBwbGljYWJsZSB0byA5
LjYpLgo+ID4gYW5kIGxldCBtZSBrbm93IGlmIGl0IG1pdGlnYXRlcyB0aGUgcHJvYmxlbT8KCk9u
IDI5LjAxLjA5IDIyOjUwLCBEbWl0cnkgUnliaW4gd3JvdGU6Cj4gT2gsIGdyZWF0IHdvcmsuIEkn
bGwgdHJ5IHRvbW9ycm93LgoKPiA+IE90aGVyIHJlY29tbWVuZGF0aW9uczoKPiA+IC0gSSBwcmV2
aW91c2x5IHN1Z2dlc3RlZCB1c2luZyBhIHNlcGFyYXRlIGNhY2hlLW9ubHkgdmlldyBhbmQgZm9y
d2FyZAo+ID4gICBhbGwgcmVjdXJzaXZlIHF1ZXJpZXMgdG8gdGhhdCB2aWV3LiAgSGF2ZSB5b3Ug
dHJpZWQgdGhhdD8gIElmIHlvdQo+ID4gICBoYXZlLCBkaWRuJ3QgaXQgd29yayBhcyBJIGhvcGVk
PwoKPiBZZXMsIEkgdHJ5IGl0LiBCdXQgSSBjYW4ndCBzZXQgdHRsIHRvIDAuIEl0IGRpZG4ndCB3
b3JrLiBSZWN1cnNpdmUgcXVlcnkKPiBmYWlscywgYW5kIGF1dGhvcml0YXRpdmUgcXVlcnkgYmFj
ayB0byBjbGllbnRzIHdpdGggdHRsIDAgIDooCgpZZXMsIHRoYXQgaXMgd2hhdCAiU2V0dGluZyBU
VEwgdG8gMCIgbWVhbnMuCgo+IH41MCB2aWV3cywgCgpjYW4ndCB5b3UgcmVhbGx5IGxvd2VyIHRo
ZSB2aWV3cyBjb3VudD8KCi0tIApNYXR1cyBVSExBUiAtIGZhbnRvbWFzLCB1aGxhckBmYW50b21h
cy5zayA7IGh0dHA6Ly93d3cuZmFudG9tYXMuc2svCldhcm5pbmc6IEkgd2lzaCBOT1QgdG8gcmVj
ZWl2ZSBlLW1haWwgYWR2ZXJ0aXNpbmcgdG8gdGhpcyBhZGRyZXNzLgpWYXJvdmFuaWU6IG5hIHR1
dG8gYWRyZXN1IGNoY2VtIE5FRE9TVEFWQVQgYWt1a29sdmVrIHJla2xhbW51IHBvc3R1LgotIEhv
bG1lcywgd2hhdCBraW5kIG9mIHNjaG9vbCBkaWQgeW91IHN0dWR5IHRvIGJlIGEgZGV0ZWN0aXZl
PwotIEVsZW1lbnRhcnksIFdhdHNvbi4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KYmluZC11c2VycyBtYWlsaW5nIGxpc3QKYmluZC11c2Vyc0BsaXN0cy5p
c2Mub3JnCmh0dHBzOi8vbGlzdHMuaXNjLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpbmQtdXNlcnM=
Dmitry Rybin
>>> and let me know if it mitigates the problem?
>
> On 29.01.09 22:50, Dmitry Rybin wrote:
>> Oh, great work. I'll try tomorrow.
Named with JINMEI Tatuy patch:
max-cache-size 800M;
Morning Statistic
version: 9.6.0-P1
CPUs found: 8
worker threads: 8
number of zones: 1040
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 167/4900/5000
tcp clients: 0/100
server is up and running
Started at Feb 3 00:51 (Now Feb 4 11:15:37) MSK
Startup mem: 890M
Cur. memory usage: 2534M
System limit: 16G
++ Incoming Requests ++
112510181 QUERY
550 IQUERY
42 STATUS
1043 RESERVED3
101299 NOTIFY
101 UPDATE
14 RESERVED11
++ Incoming Queries ++
1929 RESERVED0
75241540 A
2105214 NS
100 CNAME
276292 SOA
2490 WKS
26826476 PTR
2 HINFO
4690581 MX
236619 TXT
24 X25
2003829 AAAA
17 LOC
713837 SRV
46397 NAPTR
58 A6
1022 SPF
4 IXFR
5 AXFR
317561 ANY
23 Others
++ Outgoing Queries ++
>> Yes, I try it. But I can't set ttl to 0. It didn't work. Recursive query
>> fails, and authoritative query back to clients with ttl 0 :(
>
> Yes, that is what "Setting TTL to 0" means.
>
>> ~50 views,
>
> can't you really lower the views count?
>
It's impossible, :-( over 500'000 client use bind and we must use views
to split load on another services.
JINMEI Tatuya / 神明達哉
Dmitry Rybin <kir...@corbina.net> wrote:
> Named with JINMEI Tatuy patch:
> max-cache-size 800M;
It's way too much, if this applies to all of the 50 views.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
Dmitry Rybin
IDExOjIzOjE5ICswMzAwLAo+IERtaXRyeSBSeWJpbiA8a2lyZ3VkdUBjb3JiaW5hLm5ldD4gd3Jv
dGU6Cj4gCj4+IE5hbWVkIHdpdGggSklOTUVJIFRhdHV5IHBhdGNoOgo+PiBtYXgtY2FjaGUtc2l6
ZSA4MDBNOwo+IAo+IEl0J3Mgd2F5IHRvbyBtdWNoLCBpZiB0aGlzIGFwcGxpZXMgdG8gYWxsIG9m
IHRoZSA1MCB2aWV3cy4KPiAKCldpdGggeW91IHBhdGNoPyBUb3RhbCBtZW1vcnkgb24gc2VydmVy
IDEyR2IuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmJp
bmQtdXNlcnMgbWFpbGluZyBsaXN0CmJpbmQtdXNlcnNAbGlzdHMuaXNjLm9yZwpodHRwczovL2xp
c3RzLmlzYy5vcmcvbWFpbG1hbi9saXN0aW5mby9iaW5kLXVzZXJz
Matus UHLAR - fantomas
> Matus UHLAR - fantomas wrote:
> > can't you really lower the views count?
On 04.02.09 11:23, Dmitry Rybin wrote:
> It's impossible, :-( over 500'000 client use bind and we must use views
> to split load on another services.
Pardon? Split load? Do you use views to point different clients to different
server to lower load on them?
If so, you better should use DNS load balancing or some kind of HW/SW load
balancer
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.
Dmitry Rybin
>
> On 04.02.09 11:23, Dmitry Rybin wrote:
>> It's impossible, :-( over 500'000 client use bind and we must use views
>> to split load on another services.
> > Named with JINMEI Tatuy patch:
> > max-cache-size 800M;
> It's way too much, if this applies to all of the 50 views.
Oh! I decrease memory to 16Mb.
>
> Pardon? Split load? Do you use views to point different clients to different
> server to lower load on them?
>
> If so, you better should use DNS load balancing or some kind of HW/SW load
> balancer
>
For first time was DNS load balancing. And after grow clients base we
can use only current scheme. We think about it, but only bind with
current configuration approach to us.
Another variant - powerdns-recursor with LUA scripting. (in testing)
Matus UHLAR - fantomas
> Matus UHLAR - fantomas wrote:
>
> >
> > On 04.02.09 11:23, Dmitry Rybin wrote:
> >> It's impossible, :-( over 500'000 client use bind and we must use views
> >> to split load on another services.
>
> > > Named with JINMEI Tatuy patch:
> > > max-cache-size 800M;
>
> > It's way too much, if this applies to all of the 50 views.
>
> Oh! I decrease memory to 16Mb.
No, I did not write that. Please don't break quoting.
> > Pardon? Split load? Do you use views to point different clients to different
> > server to lower load on them?
> >
> > If so, you better should use DNS load balancing or some kind of HW/SW load
> > balancer
> >
>
> For first time was DNS load balancing. And after grow clients base we
> can use only current scheme. We think about it, but only bind with
> current configuration approach to us.
Yes, but now it seems to reach its possibilities, so you should better think
about changing your architecture...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.
JINMEI Tatuya / 神明達哉
Dmitry Rybin <kir...@corbina.net> wrote:
> >> max-cache-size 800M;
> >
> > It's way too much, if this applies to all of the 50 views.
>
> With you patch? Total memory on server 12Gb.
In case you are confused: this patch only makes named honor
max-cache-size (+ some possible margin) for each view, unlike the
unreleased new feature 'attach-cache'. Each of your 50 views can
still consume up to 800MB, so you need to expect at least 50 * 800MB
of memory footprint in the worst case.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
JINMEI Tatuya / 神明達哉
Dmitry Rybin <kir...@corbina.net> wrote:
> > > max-cache-size 800M;
>
> > It's way too much, if this applies to all of the 50 views.
>
> Oh! I decrease memory to 16Mb.
Okay, and according to this:
: Started at Feb 3 00:51 (Now Feb 4 11:15:37) MSK
: Startup mem: 890M
: Cur. memory usage: 2534M
the additional memory needed while running is 1644M (2534 - 890),
32.88M per view (if the #of view is 50). This seems to be a possible
situation, considering other memory overhead per view. If the memory
footprint is now stabilized at that point, I guess you're fine with
that, right? (and you could increase max-cache-size to, e.g., 64M).