| From: | "Matt Clark" <matt(at)ymogen(dot)net> |
|---|---|
| To: | "Rod Taylor" <rbt(at)rbt(dot)ca> |
| Cc: | "Postgresql Performance" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Hardware recommendations to scale to silly load |
| Date: | 2003-08-28 16:37:24 |
| Message-ID: | OAEAKHEHCMLBLIDGAFELIEFFDHAA.matt@ymogen.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
> Ok.. I would be surprised if you needed much more actual CPU power. I
> suspect they're mostly idle waiting on data -- especially with a Quad
> Xeon (shared memory bus is it not?).
In reality the CPUs get pegged: about 65% PG and 35% system. But I agree that memory throughput and latency is an issue.
> Write performance won't matter very much. 3000 inserts/second isn't high
> -- some additional battery backed write cache may be useful but not
> overly important with enough ram to hold the complete dataset. I suspect
> those are slow due to things like foreign keys -- which of course are
> selects.
3000 inserts/sec isn't high when they're inside one transaction, but if each is inside its own transaction then that's 3000
commits/second.
> case, additional ram will keep the system from hitting the disk for
> writes as well.
How does that work?
> You may want to play around with checkpoints. Prevention of a checkpoint
> during this hour will help prevent peaks. Be warned though, WAL will
> grow very large, and recovery time should a crash occur could be
> painful.
Good point. I'll have a think about that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ohp | 2003-08-28 16:57:02 | Re: Index creation takes for ever |
| Previous Message | Tom Lane | 2003-08-28 16:30:21 | Re: memory allocation and powers of two |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | teknokrat | 2003-08-28 17:15:57 | performance of foreign key constraints |
| Previous Message | Matt Clark | 2003-08-28 16:29:39 | Re: Hardware recommendations to scale to silly load |