public inbox for [email protected]  
help / color / mirror / Atom feed
Performance tuning for linux, 1GB RAM, dual CPU?
14+ messages / 10 participants
[nested] [flat]

* Performance tuning for linux, 1GB RAM, dual CPU?
@ 2001-07-10 11:44 Adam Manock <[email protected]>
  2001-07-10 13:21 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Janning Vygen <[email protected]>
  2001-07-10 14:06 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Philip Molter <[email protected]>
  2001-07-10 20:12 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Roderick A. Anderson <[email protected]>
  0 siblings, 3 replies; 14+ messages in thread

From: Adam Manock @ 2001-07-10 11:44 UTC (permalink / raw)
  To: pgsql-general

Hi,

I am about to put a 7.1.2 server into production on RedHat 7.1
The server will be dedicated to PostgreSQL, running a bare minimum of 
additional services.
If anyone has already tuned the configurable parameters on a dual PIII w/ 
1GB RAM then I
will have a great place to start for my performance tuning!
When I'm done I'll be posting my results here for the next first timer that 
comes along.

Thanks in advance,

Adam




^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
@ 2001-07-10 13:21 ` Janning Vygen <[email protected]>
  2 siblings, 0 replies; 14+ messages in thread

From: Janning Vygen @ 2001-07-10 13:21 UTC (permalink / raw)
  To: Adam Manock <[email protected]>; pgsql-general

Am Dienstag, 10. Juli 2001 13:44 schrieb Adam Manock:
> Hi,
>
> I am about to put a 7.1.2 server into production on RedHat 7.1
> The server will be dedicated to PostgreSQL, running a bare minimum of
> additional services.
> If anyone has already tuned the configurable parameters on a dual PIII w/
> 1GB RAM then I
> will have a great place to start for my performance tuning!

i am running the same hardware and postgresql 7.1.2
but i didnt tuned it because its fast enough for my purpose. But i am very 
interested in your investigations. Could you please pm me, if you have 
something of interest?

thanks
janning

> When I'm done I'll be posting my results here for the next first timer that
> comes along.
>
> Thanks in advance,
>
> Adam
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl

-- 
Planwerk 6 /websolutions
Herzogstra�e 86
40215 D�sseldorf

fon 0211-6015919
fax 0211-6015917
http://www.planwerk6.de



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
@ 2001-07-10 14:06 ` Philip Molter <[email protected]>
  2001-07-11 03:32   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Justin Clift <[email protected]>
  2001-07-13 00:32   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
  2 siblings, 2 replies; 14+ messages in thread

From: Philip Molter @ 2001-07-10 14:06 UTC (permalink / raw)
  To: Adam Manock <[email protected]>; +Cc: pgsql-general

On Tue, Jul 10, 2001 at 07:44:34AM -0400, Adam Manock wrote:
: Hi,
: 
: I am about to put a 7.1.2 server into production on RedHat 7.1
: The server will be dedicated to PostgreSQL, running a bare minimum of 
: additional services.
: If anyone has already tuned the configurable parameters on a dual PIII w/ 
: 1GB RAM then I
: will have a great place to start for my performance tuning!
: When I'm done I'll be posting my results here for the next first timer that 
: comes along.

I have a similar system.  It's a dual PII-450MHz Xeon with 512MB of RAM
running RH7.1 and 7.1.2.  As far as performance tuning goes, here's the
relevant lines from the postgresql.conf file we're using:

  max_connections = 64 # 1-1024
  sort_mem = 8192
  shared_buffers = 192
  fsync = false

Obviously, depending on your needs, you can adjust those.  If you've
got a 1GB of RAM, I'd set everything high and not worry about it.

* Philip Molter
* DataFoundry.net
* http://www.datafoundry.net/
* [email protected]



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
  2001-07-10 14:06 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Philip Molter <[email protected]>
@ 2001-07-11 03:32   ` Justin Clift <[email protected]>
  1 sibling, 0 replies; 14+ messages in thread

From: Justin Clift @ 2001-07-11 03:32 UTC (permalink / raw)
  To: Philip Molter <[email protected]>; +Cc: Adam Manock <[email protected]>; pgsql-general

Hi all,

Just added these figures to a new document :

http://techdocs.postgresql.org/techdocs/perftuningfigures.php

As people provide/submit figures and details of the equipment they use,
I'll post them onto this page.

Hopefully it will become a good set of real world guidelines for people,
etc.

Standardised benchmarks would be nice to though.

:-)

Regards and best wishes,

Justin Clift

Philip Molter wrote:
> 
> On Tue, Jul 10, 2001 at 07:44:34AM -0400, Adam Manock wrote:
> : Hi,
> :
> : I am about to put a 7.1.2 server into production on RedHat 7.1
> : The server will be dedicated to PostgreSQL, running a bare minimum of
> : additional services.
> : If anyone has already tuned the configurable parameters on a dual PIII w/
> : 1GB RAM then I
> : will have a great place to start for my performance tuning!
> : When I'm done I'll be posting my results here for the next first timer that
> : comes along.
> 
> I have a similar system.  It's a dual PII-450MHz Xeon with 512MB of RAM
> running RH7.1 and 7.1.2.  As far as performance tuning goes, here's the
> relevant lines from the postgresql.conf file we're using:
> 
>   max_connections = 64 # 1-1024
>   sort_mem = 8192
>   shared_buffers = 192
>   fsync = false
> 
> Obviously, depending on your needs, you can adjust those.  If you've
> got a 1GB of RAM, I'd set everything high and not worry about it.
> 
> * Philip Molter
> * DataFoundry.net
> * http://www.datafoundry.net/
> * [email protected]
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://www.postgresql.org/search.mpl



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
  2001-07-10 14:06 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Philip Molter <[email protected]>
@ 2001-07-13 00:32   ` Adam Manock <[email protected]>
  1 sibling, 0 replies; 14+ messages in thread

From: Adam Manock @ 2001-07-13 00:32 UTC (permalink / raw)
  To: Justin Clift <[email protected]>; +Cc: pgsql-general

At 01:32 PM 7/11/01 +1000, Justin Clift wrote:

 > Standardised benchmarks would be nice to though.
	Sure would be nice....

Here's some preliminary results of my testing...

System:	RedHat Linux 7.1, kernel 2.4.3smp (i686)
		Dual PIII 733 / 133FSB  1024MB RAM
		2 18Gb 10000rpm U160 SCSI drives, hardware RAID1
		
		added to /etc/sysctl.conf:
			kernel.shmmax = 268435456
			kernel.shmall = 268435456

PG 7.1.2	

postgresql-7.1.2-4PGDG binary rpm set
		
	relevant entries from postgresql.conf:
		max_connections = 32 	
		sort_mem = 4096
		shared_buffers = 32000
		fsync = true

The only benchmark I have is almost useless but I'll put it here anyway...

time ./pg_regress --schedule=parallel_schedule
(using postmaster on Unix socket, default port)
...
...
======================
  All 76 tests passed.
======================


real    0m40.784s
user    0m1.980s
sys     0m1.220s


Adam.





^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
@ 2001-07-10 20:12 ` Roderick A. Anderson <[email protected]>
  2 siblings, 0 replies; 14+ messages in thread

From: Roderick A. Anderson @ 2001-07-10 20:12 UTC (permalink / raw)
  To: Adam Manock <[email protected]>; +Cc: pgsql-general

On Tue, 10 Jul 2001, Adam Manock wrote:

> Hi,
> 
> I am about to put a 7.1.2 server into production on RedHat 7.1
> The server will be dedicated to PostgreSQL, running a bare minimum of 
> additional services.
> If anyone has already tuned the configurable parameters on a dual PIII w/ 
> 1GB RAM then I
> will have a great place to start for my performance tuning!
> When I'm done I'll be posting my results here for the next first timer that 
> comes along.

I've just did a quick read of Bruce's article in Linux Journal.  My take
is this is more than a hardware issue.  Table size, indexes (indices?)
verses sequential scans will come into play.  I don't think you can even
really test without some relevant data, queries, etc.
   Again this was a very quick read of the article.


Thanks Bruce.  It looks enlightening.

Cheers,
Rod
-- 
                 Remove the word 'try' from your vocabulary ... 
                     Don't try.  Do it or don't do it ...
                                Steers try!

                                                            Don Aslett




^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* RE: Performance tuning for linux, 1GB RAM, dual CPU?
@ 2038-07-11 15:13 Christian Bucanac <[email protected]>
  2001-07-11 16:51 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
  2001-07-11 20:42 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
  0 siblings, 2 replies; 14+ messages in thread

From: Christian Bucanac @ 2038-07-11 15:13 UTC (permalink / raw)
  To: pgsql-general

Sure, here it comes. 

/Buckis

-----Original Message-----
From: Adam Manock [mailto:[email protected]]
Sent: den 11 juli 2001 16:26
To: Christian Bucanac
Subject: RE: [GENERAL] Performance tuning for linux, 1GB RAM, dual CPU?


We should move this discussion back to the list... others may benefit.
If you're agreeable please forward your previous message to the list.

Adam


At 03:02 PM 7/11/01 +0200, you wrote:
>Yes, that is right. We did
>echo 805306368 >/proc/sys/kernel/shmax
>
>805306368 => 768MB
>
>We could not allocate 98304 buffers as you suggest, 96498 was the maximum.
>Seems like postmaster/postgres uses some mem for other things.
>
>/Buckis
>
>
>
>-----Original Message-----
>From: Adam Manock [mailto:[email protected]]
>Sent: den 11 juli 2001 14:10
>To: Christian Bucanac
>Subject: RE: [GENERAL] Performance tuning for linux, 1GB RAM, dual CPU?
>
>
>I assume you had to bump up the shmmax and shmall
>as mentioned in:
>
>http://www.ca.postgresql.org/docs/admin/kernel-resources.html
>
>Your parameters look good, close to what I am thinking
>I am going to try 768M (98304) for buffers and 6144 (6144 * 32 = 192M)
>for sort mem. This way with the DB server serving a max of 32 application
>servers the kernel and other processes should still have the last 64Mb RAM.
>This will be my starting point for testing anyway.
>
>Adam
>
>
>Adam
>
>At 10:00 AM 7/11/01 +0200, you wrote:
> >Hi!
> >
> >We have setup a Pentium III with dual 900MHz processors computer with
>RAIDed
> >disks. It is running Slackware because it is the most reliable
>distribution.
> >We have compiled and are using kernel 2.4.2 to better support dual
> >processors. The RAM is 1GB. The only perfomance tuning we have done is to
> >let the postmaster/postgres allocate as much RAM as possible. The shared
> >buffers (-B option) is set to 96498 which is about 800MB of RAM and the
>sort
> >mem size (-S) is set to 5120. The sort mem size is set this low because
> >there can be many connections to the database.
> >
> >These optimizations are enough for out environment and usage of the
>database
> >so we have not bothered to optimize it further. The database is
practically
> >running in RAM.
> >
> >/Buckis
> >
> >
> >-----Original Message-----
> >From: Adam Manock [mailto:[email protected]]
> >Sent: den 10 juli 2001 13:45
> >To: [email protected]
> >Subject: [GENERAL] Performance tuning for linux, 1GB RAM, dual CPU?
> >
> >
> >Hi,
> >
> >I am about to put a 7.1.2 server into production on RedHat 7.1
> >The server will be dedicated to PostgreSQL, running a bare minimum of
> >additional services.
> >If anyone has already tuned the configurable parameters on a dual PIII w/
> >1GB RAM then I
> >will have a great place to start for my performance tuning!
> >When I'm done I'll be posting my results here for the next first timer
that
> >comes along.
> >
> >Thanks in advance,
> >
> >Adam
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 6: Have you searched our list archives?
> >
> >http://www.postgresql.org/search.mpl




^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
@ 2001-07-11 16:51 ` Tom Lane <[email protected]>
  2001-07-11 17:47   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Steve Wolfe <[email protected]>
  2001-07-12 04:49   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tatsuo Ishii <[email protected]>
  1 sibling, 2 replies; 14+ messages in thread

From: Tom Lane @ 2001-07-11 16:51 UTC (permalink / raw)
  To: Christian Bucanac <[email protected]>; +Cc: pgsql-general

Christian Bucanac <[email protected]> writes:
>> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 = 192M)
>> for sort mem. This way with the DB server serving a max of 32 application
>> servers the kernel and other processes should still have the last 64Mb RAM.

This is almost certainly a lousy idea.  You do *not* want to chew up all
available memory for PG shared buffers; you should leave a good deal of
space for kernel-level disk buffers.

Other fallacies in the above: (1) you're assuming the SortMem parameter
applies once per backend, which is not the case (it's once per sort or
hash step in a query, which could be many times per backend); (2) you're
not allowing *anything* for any space usage other than shared disk
buffers and sort memory.

The rule of thumb I recommend is to use (at most) a quarter of real RAM
for shared disk buffers.  I don't have hard measurements to back that
up, but I think it's a lot more reasonable as a starting point than
three-quarters of RAM.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
  2001-07-11 16:51 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
@ 2001-07-11 17:47   ` Steve Wolfe <[email protected]>
  1 sibling, 0 replies; 14+ messages in thread

From: Steve Wolfe @ 2001-07-11 17:47 UTC (permalink / raw)
  To: pgsql-general


> Christian Bucanac <[email protected]> writes:
> >> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 =
192M)
> >> for sort mem. This way with the DB server serving a max of 32
application
> >> servers the kernel and other processes should still have the last
64Mb RAM.
>
> This is almost certainly a lousy idea.  You do *not* want to chew up all
> available memory for PG shared buffers; you should leave a good deal of
> space for kernel-level disk buffers.

  I'll second that.  The way that I tuned our installation was:

1.  Make sure you have enough RAM that the data files are *always* in
cache, and that all apps have enough RAM available for them.
2.  Increase shared buffers until there was no performance increase, then
double it.
3.  Increase sort memory until there was no performance increase, then
double it.
4.  Turn off fsync().
5.  Make sure that #1 still applies.

  In our system (1.5 gigs), that ended up being 128 megs of shared
buffers, and 64 megs for sorting.  Some day, I'll probably increase the
shared buffers more (just because I can), but currently, Linux doesn't
seem to let me set SHMMAX over 128 megs.  Some day I'll look into it. : )

steve





^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
  2001-07-11 16:51 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
@ 2001-07-12 04:49   ` Tatsuo Ishii <[email protected]>
  2001-07-12 14:20     ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
  1 sibling, 1 reply; 14+ messages in thread

From: Tatsuo Ishii @ 2001-07-12 04:49 UTC (permalink / raw)
  To: [email protected]; +Cc: [email protected]; pgsql-general

> Christian Bucanac <[email protected]> writes:
> >> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 = 192M)
> >> for sort mem. This way with the DB server serving a max of 32 application
> >> servers the kernel and other processes should still have the last 64Mb RAM.
> 
> This is almost certainly a lousy idea.  You do *not* want to chew up all
> available memory for PG shared buffers; you should leave a good deal of
> space for kernel-level disk buffers.
> 
> Other fallacies in the above: (1) you're assuming the SortMem parameter
> applies once per backend, which is not the case (it's once per sort or
> hash step in a query, which could be many times per backend); (2) you're
> not allowing *anything* for any space usage other than shared disk
> buffers and sort memory.
> 
> The rule of thumb I recommend is to use (at most) a quarter of real RAM
> for shared disk buffers.  I don't have hard measurements to back that
> up, but I think it's a lot more reasonable as a starting point than
> three-quarters of RAM.

In my testing with *particluar* environment (Linux kernel 2.2.x,
pgbench), it was indicated that too many shared buffers reduced the
performance even though there was lots of memory, say 1GB. I'm not
sure why, but I suspect there is a siginificant overhead to lookup
shared buffers.
--
Tatsuo Ishii



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
  2001-07-11 16:51 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
  2001-07-12 04:49   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tatsuo Ishii <[email protected]>
@ 2001-07-12 14:20     ` Tom Lane <[email protected]>
  2001-07-12 17:18       ` Re: Performance tuning for linux, 1GB RAM, dual CPU? snpe <[email protected]>
  0 siblings, 1 reply; 14+ messages in thread

From: Tom Lane @ 2001-07-12 14:20 UTC (permalink / raw)
  To: Tatsuo Ishii <[email protected]>; +Cc: [email protected]; pgsql-general

Tatsuo Ishii <[email protected]> writes:
> In my testing with *particluar* environment (Linux kernel 2.2.x,
> pgbench), it was indicated that too many shared buffers reduced the
> performance even though there was lots of memory, say 1GB. I'm not
> sure why, but I suspect there is a siginificant overhead to lookup
> shared buffers.

Regular lookups use a hash table, and shouldn't suffer much from
degraded performance as NBuffers rises.  However, there are some
operations that do a linear scan of all the buffers --- table deletion
comes to mind.  Perhaps your test was exercising one of these.

pgbench doesn't do table deletions of course... hmm... the only
such loop in bufmgr.c that looks like it would be executed during
normal transactions is BufferPoolCheckLeak().  Maybe we should
make that routine be a no-op unless assert checking is turned on?
Have we reached the point where performance is more interesting than
error checking?  It'd be interesting to retry your results with
BufferPoolCheckLeak() reduced to "return false".

Another factor, not under our control, is that if the shared memory
region gets too large the kernel may decide to swap out portions of
it that haven't been touched lately.  This of course is completely
counterproductive, especially if what gets swapped is a dirty buffer,
which'll eventually have to be read back in and then written to where
it should have gone.  This is the main factor behind my thought that you
don't want to skimp on kernel disk buffer space --- any memory pressure
in the system should be resolvable by dropping kernel disk buffers, not
by starting to swap shmem or user processes.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
  2001-07-11 16:51 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
  2001-07-12 04:49   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tatsuo Ishii <[email protected]>
  2001-07-12 14:20     ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Tom Lane <[email protected]>
@ 2001-07-12 17:18       ` snpe <[email protected]>
  0 siblings, 0 replies; 14+ messages in thread

From: snpe @ 2001-07-12 17:18 UTC (permalink / raw)
  To: pgsql-general


> Another factor, not under our control, is that if the shared memory
> region gets too large the kernel may decide to swap out portions of
> it that haven't been touched lately.  This of course is completely
> counterproductive, especially if what gets swapped is a dirty buffer,
> which'll eventually have to be read back in and then written to where
> it should have gone.  This is the main factor behind my thought that you
> don't want to skimp on kernel disk buffer space --- any memory pressure
> in the system should be resolvable by dropping kernel disk buffers, not
> by starting to swap shmem or user processes.
>

You can lock shared memory for this problem ?


regards
haris peco




^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
@ 2001-07-11 20:42 ` Adam Manock <[email protected]>
  2001-07-11 20:50   ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Justin Clift <[email protected]>
  1 sibling, 1 reply; 14+ messages in thread

From: Adam Manock @ 2001-07-11 20:42 UTC (permalink / raw)
  To: pgsql-general

 >This is almost certainly a lousy idea.  You do *not* want to chew up all
 >available memory for PG shared buffers; you should leave a good deal of
 >space for kernel-level disk buffers.

I decided to start high on buffers because of Bruce's:
	http://www.ca.postgresql.org/docs/hw_performance/
 From that I get the impression that operations using kernel disk buffer
cache are considerably more expensive than if the data was in shared
buffer cache, and that increasing PG's memory usage until the system
is almost using swap is The Right Thing To Do.  Has anyone got real
world test data to confirm or refute this??
    If not, then I am going to need to find or create a benchmarking program
to load down PG against a fake multi-gigabyte "production" database.
Or I could wait a week to see what RedHat does to tune their
implementation of PG :-)

Adam




^ permalink  raw  reply  [nested|flat] 14+ messages in thread

* Re: Performance tuning for linux, 1GB RAM, dual CPU?
  2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
  2001-07-11 20:42 ` Re: Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
@ 2001-07-11 20:50   ` Justin Clift <[email protected]>
  0 siblings, 0 replies; 14+ messages in thread

From: Justin Clift @ 2001-07-11 20:50 UTC (permalink / raw)
  To: Adam Manock <[email protected]>; +Cc: pgsql-general

Hi Adam,

There are a few links to benchmark-type things you might find useful at
:

http://techdocs.postgresql.org/oresources.php#benchmark

Hope they're useful.

:-)

Regards and best wishes,

Justin Clift

Adam Manock wrote:
> 
>  >This is almost certainly a lousy idea.  You do *not* want to chew up all
>  >available memory for PG shared buffers; you should leave a good deal of
>  >space for kernel-level disk buffers.
> 
> I decided to start high on buffers because of Bruce's:
>         http://www.ca.postgresql.org/docs/hw_performance/
>  From that I get the impression that operations using kernel disk buffer
> cache are considerably more expensive than if the data was in shared
> buffer cache, and that increasing PG's memory usage until the system
> is almost using swap is The Right Thing To Do.  Has anyone got real
> world test data to confirm or refute this??
>     If not, then I am going to need to find or create a benchmarking program
> to load down PG against a fake multi-gigabyte "production" database.
> Or I could wait a week to see what RedHat does to tune their
> implementation of PG :-)
> 
> Adam
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [email protected]



^ permalink  raw  reply  [nested|flat] 14+ messages in thread


end of thread, other threads:[~2038-07-11 15:13 UTC | newest]

Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-07-10 11:44 Performance tuning for linux, 1GB RAM, dual CPU? Adam Manock <[email protected]>
2001-07-10 13:21 ` Janning Vygen <[email protected]>
2001-07-10 14:06 ` Philip Molter <[email protected]>
2001-07-11 03:32   ` Justin Clift <[email protected]>
2001-07-13 00:32   ` Adam Manock <[email protected]>
2001-07-10 20:12 ` Roderick A. Anderson <[email protected]>
2038-07-11 15:13 RE: Performance tuning for linux, 1GB RAM, dual CPU? Christian Bucanac <[email protected]>
2001-07-11 16:51 ` Tom Lane <[email protected]>
2001-07-11 17:47   ` Steve Wolfe <[email protected]>
2001-07-12 04:49   ` Tatsuo Ishii <[email protected]>
2001-07-12 14:20     ` Tom Lane <[email protected]>
2001-07-12 17:18       ` snpe <[email protected]>
2001-07-11 20:42 ` Adam Manock <[email protected]>
2001-07-11 20:50   ` Justin Clift <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox