From: | Tobias Brox <tobias(at)nordicbet(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Tobias Brox <tobias(at)nordicbet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Swappiness setting on a linux pg server |
Date: | 2006-10-19 16:53:49 |
Message-ID: | 20061019165349.GE31916@oppetid.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
[Jim C. Nasby - Thu at 11:45:32AM -0500]
> > > The issue with pg_xlog is you don't need bandwidth... you need super-low
> > > latency. The best way to accomplish that is to get a battery-backed RAID
> > > controller that you can enable write caching on.
> >
> > Sounds a bit risky to me :-)
>
> Well, you do need to understand what happens if the machine does lose
> power... namely you have a limited amount of time to get power back to
> the machine so that the controller can flush that data out. Other than
> that, it's not very risky.
We have burned ourself more than once due to unreliable raid controllers
...
> quantities of memory. So in your case, 600M wouldn't be pushing things
> much at all. Even 1G wouldn't be that out of the ordinary. Also remember
> that the more memory for shared_buffers, the less for
> sorting/hashes/etc. (work_mem)
What do you mean, a high value for the shared_buffers implicates I
can/should lower the work_mem value? Or just that I should remember to
have more than enough memory for both work_mem, shared_buffers and OS
caches? What is a sane value for the work_mem? It's currently set to
8M.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-10-19 17:00:39 | Re: Swappiness setting on a linux pg server |
Previous Message | Jim C. Nasby | 2006-10-19 16:45:32 | Re: Swappiness setting on a linux pg server |