Re: DB cache size strategies

From: Richard Huxton <dev(at)archonet(dot)com>
To: "NTPT" <ntpt(at)centrum(dot)cz>, "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: DB cache size strategies
Date: 2004-02-11 10:59:18
Message-ID: 200402111059.18913.dev@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday 11 February 2004 09:42, NTPT wrote:
>
> It seems that :
>
> 1: Settings memory limits too high, whnen machine start using swap space
> is WROSE then give postgres as low memory as possible.

Swapping is always bad news.

> 2: settings of sort_mem have bigger impact on performance then settings
> of effective_cache_size , if db cache hold at least hunderds of disk
> pages. More than 1000 disk pages in effective cache size have no sense.
>
> I can not made reliable simulations with this database on real user load
> :(, so with more concurent user result may be different. May be a good
> "stress test" suite for postgresql database is needed for future testings.

It will be radically different with concurrent users. Your large sort_mem will
apply to every sort they do and so you will probably end up going into swap
again.

This is one of the reasons why performance tuning is complicated, and you need
to test a real-world workload wherever possible.
--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Erwin Van de Velde 2004-02-11 11:12:17 Converting timestamps and IP addresses
Previous Message William ZHANG 2004-02-11 10:08:10 Re: pg_class and relfilenode