[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pdns-users
Subject:    Re: [Pdns-users] v3.1 memory leak?
From:       Stefan Schmidt <zaphodb () zaphods ! net>
Date:       2012-07-06 13:08:39
Message-ID: CAFoxyLUQVQNuajtPu7i1oF31cCRZraFWBnbJk9MtXDBrhx_9DQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Jul 6, 2012 at 2:21 PM, Peter Gervai <grinapo+pdnsdevel@gmail.com>wrote:

> Hello,
>

Hi Peter,

I am using Debian/sid packaged v3.1-1. This config is a bit peculiar:
> receives AXFRs for a given domain mostly every minute, and the zone
> contains a few thousands of hosts. pdns uses psql backend.
>
> It survives usually 1-2 weeks without OOM. I see no obvious way to
> control memory usage of pdns server, and leaving it working usually
> reaches gigabytes pretty fast from the supposedly normal 3-400MB size.


PowerDNS server uses several caches, all of which you can limit in the
amount of time (TTL) that they store entries for.
See http://doc.powerdns.com/all-settings.html *cache-ttl
and http://doc.powerdns.com/performance-settings.html
By default i think packet cache and query cache will allow for storing the
cache entries for a potentially unlimited amount of time - or rather for
the TTL that they actually have configured in the respective backends.
If you also have many clients querying your server for recursive answers
you may want to take an extra careful look at the negative caching ttl
which by default is set to 60 seconds.

Basically what i'm saying is that queries to your server can cause memory
usage and potentially gigabytes of that if these values are not limited and
you're getting a lot of queries.

 Stefan

[Attachment #5 (text/html)]

<div class="gmail_quote">On Fri, Jul 6, 2012 at 2:21 PM, Peter Gervai <span \
dir="ltr">&lt;<a href="mailto:grinapo+pdnsdevel@gmail.com" \
target="_blank">grinapo+pdnsdevel@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Hello,<br></blockquote><div><br></div><div>Hi Peter,  \
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> I am using Debian/sid packaged \
v3.1-1. This config is a bit peculiar:<br> receives AXFRs for a given domain mostly \
every minute, and the zone<br> contains a few thousands of hosts. pdns uses psql \
backend.<br> <br>
It survives usually 1-2 weeks without OOM. I see no obvious way to<br>
control memory usage of pdns server, and leaving it working usually<br>
reaches gigabytes pretty fast from the supposedly normal 3-400MB \
size.</blockquote><div><br></div><div>PowerDNS server uses several caches, all of \
which you can limit in the amount of time (TTL) that they store entries for.</div> \
<div>See <a href="http://doc.powerdns.com/all-settings.html">http://doc.powerdns.com/all-settings.html</a> \
*cache-ttl</div><div>and  <a \
href="http://doc.powerdns.com/performance-settings.html">http://doc.powerdns.com/performance-settings.html</a></div>
 <div>By default i think packet cache and query cache will allow for storing the \
cache entries for a potentially unlimited amount of time - or rather for the TTL that \
they actually have configured in the respective backends.</div> <div>If you also have \
many clients querying your server for recursive answers you may want to take an extra \
careful look at the negative caching ttl which by default is set to 60 \
seconds.</div><div><br></div><div>Basically what i&#39;m saying is that queries to \
your server can cause memory usage and potentially gigabytes of that if these values \
are not limited and you&#39;re getting a lot of queries.</div> <div><br></div><div>  \
Stefan</div></div>



_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic