Re: Tuning for a tiny database

On Jun 20, 2011, at 10:49 PM, CSS wrote:

> Hello,
>
> I couldn't find much information in the archives on this -- perhaps this
> is a bit of a specialized need, but I was hoping for some input from
> some experienced postgres admins.
>
> I'm moving some DNS servers from djbdns/tinydns to PowerDNS. While it
> supports many backends, postgresql seems like the best choice for us
> since it's what is used elsewhere (in larger configurations). As a bit
> of background, PowerDNS does not query the db for every incoming DNS
> query, it caches at various levels (both a "packet cache" and a db
> cache), so it's database needs are quite modest.
>
> Some raw numbers: We're only looking at a total of about six tables in
> one db. In total there are going to be well under 10,000 records in ALL
> tables. That might increase to at most 100,000 in the next few years.
> Our raw DNS queries/second tops out around 50 qps over three distinct
> servers. Keeping in mind that PowerDNS is doing heavy caching, we
> should never really see more than a few db queries per second. There
> will be one "master" pgsql db and three slaves using streaming replication.
>
> Now given the number of records and the frequency of queries, how should
> I be tuning for such a small setup? Ideally PowerDNS with it's huge
> amount of caching should get as much RAM and CPU as I can give it, but I
> do want to ensure the tiny bit of data postgres has is stuck in physical
> memory as well.
>
> What would you suggest for this scenario?

I'm doing pretty much the same thing. I installed postgresql 8.4.something and
powerdns from the ubuntu repository on a small VM and hit go. It's running just
fine, at comparable query rates and maybe 5,000 records. At some point I'll
tune it, just out of tidiness, but it's fine out of the box.

You'll also need replication, probably from a stealth master. I found bucardo
very easy to set up for that, and it works nicely to replicate to multiple public
servers from a single master server inside the firewall.

Cheers,
Steve