From: | Anj Adu <fotographs(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Vacuum analyse after a long time without one ... |
Date: | 2009-09-11 18:13:25 |
Message-ID: | f2fd819a0909111113q2995dfc7m63ecd71e583b8dd4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
For a 64 bit machine..does the higher shared buffer setting really
offer a significant improvement over a 32 bit lower setting coupled
with linux caching ? Is the postgres shared buffer algorithm superior
to the linux caching algorithm to favor a switch to 64 bit
On Fri, Sep 11, 2009 at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nicolas Michel <nicolas(dot)michel(at)lemail(dot)be> writes:
>> - I have 16Go of RAM on that server (but 32bits OS with bigmem kernel ;
>> so I set shared buffer to 350000 (~2,7GB) for a shmmax of 4000000000
>> (~3,8GB)
>
> On a 32-bit machine that's just insane. You've got something like 300MB
> left over in the process address space (assuming the typical 1Gb for
> kernel split). No wonder things are falling over. Try putting
> shared_buffers somewhere around 1Gb. Or switch to 64-bit.
>
> regards, tom lane
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-11 18:20:08 | Re: Vacuum analyse after a long time without one ... |
Previous Message | Nicolas Michel | 2009-09-11 18:05:39 | Re: Vacuum analyse after a long time without one ... |