| From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
|---|---|
| To: | "Christopher Browne" <cbbrowne(at)acm(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: my boss want to migrate to ORACLE |
| Date: | 2004-07-31 04:14:41 |
| Message-ID: | 1091247281.27159.726.camel@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, 2004-07-30 at 19:22, Christopher Browne wrote:
> After a long battle with technology, stephane(dot)tessier(at)abovesecurity(dot)com ("Stephane Tessier"), an earthling, wrote:
> > I think with your help guys I'll do it!
> >
> > I'm working on it!
> >
> > I'll work on theses issues:
> >
> > we have space for more ram(we use 2 gigs on possibility of 3 gigs)
>
> That _may_ help; not completely clear.
>
> > iowait is very high 98% --> look like postgresql wait for io access
>
> In that case, if you haven't got a RAID controller with battery backed
> cache, then that should buy you a BIG boost in performance. Maybe
> $1500 USD; that could be money FABULOUSLY well spent.
>
> > raid5 -->raid0 if i'm right raid5 use 4 writes(parity,data, etc) for each
> > write on disk
>
> I try to avoid talking about RAID levels, and leave them to others
> :-).
FYI, in a previous post on this topic, the original poster put up a top
output that showed the machine using 2 gigs of swap with 150 Meg for
kernel cache, and all the memory being used by a few postgresql
processes. The machine was simply configured to give WAY too much
memory to shared buffers and sort mem and this was likely causing the
big slowdown.
Adding a battery backed caching RAID controller and properly configuring
postgresql.conf should get him into the realm of reasonable performance.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-08-01 11:42:33 | SSD Drives |
| Previous Message | Christopher Browne | 2004-07-31 01:22:25 | Re: my boss want to migrate to ORACLE |