From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Francisco Reyes <lists(at)stringsutils(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Vacuums on large busy databases |
Date: | 2006-09-15 00:59:26 |
Message-ID: | 1158281966.29889.207.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2006-09-14 at 20:07 -0400, Dave Cramer wrote:
> On 14-Sep-06, at 7:50 PM, Francisco Reyes wrote:
>
> > Dave Cramer writes:
> >
> >> personally, I'd set this to about 6G. This doesn't actually
> >> consume memory it is just a setting to tell postgresql how much
> >> memory is being used for cache and kernel buffers
> >
> > Gotcha. Will increase further.
> >
> >> regarding shared buffers I'd make this much bigger, like 2GB or more
> >
> > Will do 2GB on the weekend. From what I read this requires shared
> > memory so have to restart my machine (FreeBSD).
> >
> > if I plan to give shared buffers 2GB, how much more over that
> > should I give the total shared memory kern.ipc.shmmax? 2.5GB?
>
> I generally make it slightly bigger. is shmmax the size of the
> maximum chunk allowed or the total ?
That's the total on FreeBSD, per process. I think to allow more than 2GB
there you may need a special compile option in the kernel.
> > Also will shared buffers impact inserts/updates at all?
> > I wish the postgresql.org site docs would mention what will be
> > impacted.
> Yes, it will, however not as dramatically as what you are seeing with
> effective_cache
> >
> > Comments like: This setting must be at least 16, as well as at
> > least twice the value of max_connections; however, settings
> > significantly higher than the minimum are usually needed for good
> > performance.
> >
> > Are usefull, but could use some improvement.. increase on what? All
> > performance? inserts? updates? selects?
> >
> > For instance, increasing effective_cache_size has made a noticeable
> > difference in selects. However as I talk to the developers we are
> > still doing marginally in the inserts. About 150/min.
> The reason is that with effective_cache the select plans changed (for
> the better) ; it's unlikely that the insert plans will change.
There aren't multiple INSERT plans (however, there could be a subselect
or something, which would be planned separately). INSERT is INSERT. That
means effective_cache_size will have zero effect on INSERT.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2006-09-15 01:04:32 | Re: Vacuums on large busy databases |
Previous Message | Jeff Davis | 2006-09-15 00:52:02 | Re: Vacuums on large busy databases |