Re: [performance] fast reads on a busy server
| От | Willy-Bas Loos |
|---|---|
| Тема | Re: [performance] fast reads on a busy server |
| Дата | |
| Msg-id | CAHnozThsAoNO5AFcdMy+HDWXoVJw5i-NoZuij7OoEhHsWc57PQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [performance] fast reads on a busy server (Willy-Bas Loos <willybas@gmail.com>) |
| Ответы |
Re: [performance] fast reads on a busy server
Re: [PERFORM] [performance] fast reads on a busy server |
| Список | pgsql-cluster-hackers |
On Wed, Jun 27, 2012 at 12:01 PM, Willy-Bas Loos <willybas@gmail.com> wrote:
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
-- 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
В списке pgsql-cluster-hackers по дате отправления: