Skip site navigation (1) Skip section navigation (2)

Re: max_fsm_pages, shared_buffers and checkpoint_segments

From: Ben <bench(at)silentmedia(dot)com>
To: "Y Sidhu" <ysidhu(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: max_fsm_pages, shared_buffers and checkpoint_segments
Date: 2007-05-23 17:00:22
Message-ID: 86F7C6E1-0D2D-4D47-8F11-9A4C9D3CDFE7@silentmedia.com (view raw or flat)
Thread:
Lists: pgsql-performance
Mass deletes are expensive to clean up after. Truncates are better if  
you can, but, as it sounds like you can't, you might look into  
vacuum_cost_delay and its many variables. It will make your vacuums  
run longer, not shorter, but it will also make them have less of an  
impact, if you configure it properly for your workload.

As you've found out, it's probably better not to poke things randomly  
in the hope of making it faster.

On May 23, 2007, at 9:43 AM, Y Sidhu wrote:

> I cannot answer that question on the grounds that it may  
> incriminate me. Hehe. I am really trying to get our vacuum times  
> down. The cause of the problem, I believe, are daily mass deletes.  
> Yes, I am working on performing vacuums more than once a day. No, I  
> am not considering partitioning the offending table because a few  
> scripts have to be changed. I am also turning the knobs as I find  
> them.
>
> Any help is appreciated b'cause "I can't hold er t'gether much  
> longer kap'n." Sorry, that's the best 'Scotty' I can do this morning.
>
> Yudhvir
> =============
>
> On 5/23/07, Ben <bench(at)silentmedia(dot)com> wrote:
> Do you have an overall plan (besides "make it go faster!") or are you
> just trying out the knobs as you find them?
>
> This may be helpful:
> http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
>
> On May 23, 2007, at 9:22 AM, Y Sidhu wrote:
>
> > I am a newbie, as you all know, but I am still embarassed asking
> > this question. I started my tuning career by changing
> > shared_buffers. Soon I discovered that I was hitting up against the
> > available RAM on the system. So, I brought the number down. Then I
> > discovered max_fsm_pages. I could take that up quite high and found
> > out that it is a 'disk' thing. Then I started increasing
> > checkpoint_segments,which is also a disk thing. However, setting it
> > to 25, and then increasing any of the other 2 variables, the
> > postgresql daemon stops working. meaning it does not start upon
> > reboot. When I bring shared_buffers or max_fsm_pages back down, the
> > daemon starts and all is normal. This happens on a 1 GB RAM machine
> > and a 4 GB RAM machine.
> >
> > Anyone know what I am doing wrong?
> >
> > System:  FreeBSD 6.1, Postgresql 8.09, 2 GB RAM
> >
> > --
> > Yudhvir Singh Sidhu
> > 408 375 3134 cell
>
>
>
>
> -- 
> Yudhvir Singh Sidhu
> 408 375 3134 cell

In response to

pgsql-performance by date

Next:From: PFCDate: 2007-05-23 17:56:11
Subject: Re: max_fsm_pages, shared_buffers and checkpoint_segments
Previous:From: Y SidhuDate: 2007-05-23 16:43:36
Subject: Re: max_fsm_pages, shared_buffers and checkpoint_segments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group