Thread: first postgrreSQL tunning
Hi there! I'm doing my first tunning on my postgreSQL, my server is for a small app, largest table shall never exceed 10k rows, and less than 1k transactions/day. So I don't think I should run out of resources. The machine is a Fedora Core 3.0 with 1gb ran and kernel 2.6. I'm thinking in having 50 connections limit, so besides semaphores should I do anything special on kernel parameters. The app is so small that during late night time almost no one will access so, I'm thinking in full vacuuming it every day at 1:00AM. Any tips are very very welcome :D Thanks all
> Hi there! I'm doing my first tunning on my postgreSQL, my server is for > a small app, largest table shall never exceed 10k rows, and less than 1k > transactions/day. So I don't think I should run out of resources. The > machine is a Fedora Core 3.0 with 1gb ran and kernel 2.6. I'm thinking > in having 50 connections limit, so besides semaphores should I do > anything special on kernel parameters. The app is so small that during > late night time almost no one will access so, I'm thinking in full > vacuuming it every day at 1:00AM. The biggest danger with small databases is it's easy to become overconfident...writing poor queries and such and not properly indexing. 50 users can hit your system pretty hard if they all decide to do something at once. Aside from that, just remember to bump up work_mem a bit for fast joining. Your application may be small, but if it is written well and works, it well inevitably become larger and more complex, so plan for the future :) Merlin
Merlin Moncure wrote: >>Hi there! I'm doing my first tunning on my postgreSQL, my server is >> >> >for > > >>a small app, largest table shall never exceed 10k rows, and less than >> >> >1k > > >>transactions/day. So I don't think I should run out of resources. The >>machine is a Fedora Core 3.0 with 1gb ran and kernel 2.6. I'm thinking >>in having 50 connections limit, so besides semaphores should I do >>anything special on kernel parameters. The app is so small that during >>late night time almost no one will access so, I'm thinking in full >>vacuuming it every day at 1:00AM. >> >> > >The biggest danger with small databases is it's easy to become >overconfident...writing poor queries and such and not properly indexing. >50 users can hit your system pretty hard if they all decide to do >something at once. Aside from that, just remember to bump up work_mem a >bit for fast joining. > >Your application may be small, but if it is written well and works, it >well inevitably become larger and more complex, so plan for the future >:) > >Merlin > > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > > Thanks Merlin, besides what I said of tunning anything else I should care looking at?
On Thu, 06 Jan 2005 11:19:51 -0200 Vinicius Caldeira Carvalho <vinicius.carvalho@squadra.com.br> wrote: > Hi there! I'm doing my first tunning on my postgreSQL, my server is > for a small app, largest table shall never exceed 10k rows, and less > than 1k transactions/day. So I don't think I should run out of > resources. The machine is a Fedora Core 3.0 with 1gb ran and kernel > 2.6. I'm thinking in having 50 connections limit, so besides > semaphores should I do anything special on kernel parameters. The app > is so small that during late night time almost no one will access so, > I'm thinking in full vacuuming it every day at 1:00AM. > > Any tips are very very welcome :D You'll want to tune shared_buffers and sort_mem. Possibly also effective_cache_size. It really depends on your system. Having tuned a ton of apps to work with PostgreSQL what I usually do is write a small script that does the major resource intensive queries on the database and time it. Tweak a PostgreSQL parameter and re-run, wash, rinse, repeat until I get what I believe is the best performance I can. --------------------------------- Frank Wiles <frank@wiles.org> http://www.wiles.org ---------------------------------