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

Re: Server Hardware Configuration

From: "John Jensen" <jrj(at)ft(dot)fo>
To: <pgsql-admin(at)postgresql(dot)org>,<sofkam(at)rpi(dot)edu>
Subject: Re: Server Hardware Configuration
Date: 2005-11-19 00:15:46
Message-ID: s37e6ec8.028@fs3.ft.fo (view raw or flat)
Thread:
Lists: pgsql-admin
Performance questions are terrible to answer because 
we all use our systems in different ways. Here's my 
2 bits for what they're worth.

> The idea behind the first is to keep the
> entire database in memory, by way of the disk cache.

What you describe is a real-time system. Does your 
requirements call for real-time performance ?
Remember that performance from memory is much more 
expensive than disk i/o (at least up to a certain point).

> A web interface allows people to accept, or (usually) 
> discard the trapped messages.

IMHO this means no real-time.

> So, most data is write once, read at most once, delete.

This is not exactly an optimum case for caching. I would
suggest thinking really hard before going for an all memory
solution. From what you write I would suggest a firm focus 
on disc i/o.

But in the end the best person to ask really is yourself.
How is the system loaded ? Is disk i/o maxed out ?
Are the cpu's overload'ed ? Is it paging like cracy ?

I suggest looking at your current bottleneck first.
It's likely to be the most cost-efficient route out.

Could also be some magic pg tunning tricks out there
you've missed. Who knows. I spent two weeks on google
and tuning last year with amazing results.

Also remember that pg collects performance statistics. 
Those will help a lot in finding out what's really 
going on. This can also reveal where the database is 
being used inefficient by the application, missing 
index'es etc.

At present I'm running a 130gig base on a 4gig mem 
four way 6650 with an external (fiber channel) raid 
5 box.

I admit the load is not that terrible or time sensitive
(web self-service) but the performance is still pretty
hot. The requests are very scattered so i/o is key. My
cache benefit is mostly from the index's.

Good luck in your quest for "bang per buck" ;-)

Cheers,

John

pgsql-admin by date

Next:From: Guido BarosioDate: 2005-11-19 00:29:54
Subject: Re: COPY and partitioning
Previous:From: Tom LaneDate: 2005-11-18 23:59:25
Subject: Re: fsm allocation

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