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

Re: [performance] fast reads on a busy server

From: Willy-Bas Loos <willybas(at)gmail(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: pgsql-cluster-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org, Greg Smith <greg(at)2ndquadrant(dot)com>
Subject: Re: [performance] fast reads on a busy server
Date: 2012-06-27 11:28:39
Message-ID: CAHnozThsAoNO5AFcdMy+HDWXoVJw5i-NoZuij7OoEhHsWc57PQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-cluster-hackerspgsql-performance
On Wed, Jun 27, 2012 at 12:01 PM, Willy-Bas Loos <willybas(at)gmail(dot)com> wrote:

> I cannot follow that reasoning completely. Who needs OS level file cache
> when postgres' shared_buffers is better? The efficiency should go up again
> after passing 50% of shared buffers, where you would be caching everything
> twice.
> The only problem i see is that work_mem and such will end up in SWAP if
> there isn't enough memory left over to allocate.\


That is, 25% probably works best when there is only one cluster.
I'm just wondering about this particular case:
* more than 1 cluster on the machine, no separate file systems.
* need fast writes on one cluster, so steal some memory to fit the DB in
shared_buffers
* now there is useless data in the OS file-cache

Should i use a larger shared_buffers for the other cluster(s) too, so that
i bypass the inefficient OS file-cache?

Cheers,

WBL
-- 
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth

In response to

Responses

pgsql-performance by date

Next:From: Willy-Bas LoosDate: 2012-06-27 11:58:06
Subject: Re: [performance] fast reads on a busy server
Previous:From: Willy-Bas LoosDate: 2012-06-27 10:01:51
Subject: Re: [performance] fast reads on a busy server

pgsql-cluster-hackers by date

Next:From: Willy-Bas LoosDate: 2012-06-27 11:58:06
Subject: Re: [performance] fast reads on a busy server
Previous:From: Willy-Bas LoosDate: 2012-06-27 10:01:51
Subject: Re: [performance] fast reads on a busy server

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