One big caveat re. the "SAME" striping strategy, is that readahead can
really hurt an OLTP you.
Mind you, if you're going from a few disks to a caching array with many
disks, it'll be hard to not have a big improvement
But if you push the envelope of the array with a "SAME" configuration,
read
I'm confused why you say the system is 70% busy: the vmstat output
shows 70% *idle*.
The vmstat you sent shows good things and ambiguous things:
- si and so are zero, so your not paging/swapping. Thats always step
1. you're fine.
- bi and bo (physical IO) shows pretty high numbers for how many
2004, Paul Tuckfield wrote:
If you are having a "write storm" or bursty writes that's burying
performance, a scsi raid controler with writeback cache will greatly
improve the situation, but I do believe they run around $1-2k. If
it's write specific problem, the cache matte
it's very good to understand specific choke points you're trying to
address by upgrading so you dont get disappointed. Are you truly CPU
constrained, or is it memory footprint or IO thruput that makes you
want to upgrade?
IMO The best way to begin understanding system choke points is vmstat
o
The king of statistics in these cases, is probably vmstat. one can
drill down on specific things from there, but first you should send
some vmstat output.
Reducing cache -> reducing IO suggests to me the OS might be paging out
shared buffers. This is indicated by activity in the "si" and "so
I'm guessing you have a 4 cpu box:
1 99 percent busy process on a 4 way box == about 25% busy overall.
On May 5, 2004, at 6:03 AM, Tom Lane wrote:
"Cyrille Bonnet" <[EMAIL PROTECTED]> writes:
Should I be worried that Postgres is eating up 99% of my CPU??? Or is
this
*expected* behaviour?
It's not
Dave:
Why would test and set increase context swtches:
Note that it *does not increase* context swtiches when the two threads
are on the two cores of a single Xeon processor. (use taskset to force
affinity on linux)
Scenario:
If the two test and set processes are testing and setting the same bi
.)
On Apr 20, 2004, at 1:02 PM, Paul Tuckfield wrote:
I tried to test how this is related to cache coherency, by forcing
affinity of the two test_run.sql processes to the two cores
(pipelines? threads) of a single hyperthreaded xeon processor in an
smp xeon box.
When the processes are allowed to
I tried to test how this is related to cache coherency, by forcing
affinity of the two test_run.sql processes to the two cores (pipelines?
threads) of a single hyperthreaded xeon processor in an smp xeon box.
When the processes are allowed to run on distinct chips in the smp box,
the CS storm h
Not that I'm offering to do the porgramming mind you, :) but . .
In the case of select count(*), one optimization is to do a scan of the
primary key, not the table itself, if the table has a primary key. In a
certain commercial, lesser database, this is called an "index fast full
scan". It wou
(hope I'm posting this correctly)
You wrote:
>First question is do we gain anything by moving the RH Enterprise
>version of Linux in terms of performance, mainly in the IO realm as we
>are not CPU bound at all? Second and more radical, has anyone run
>postgreSQL on the new Apple G5 with an XRaid
11 matches
Mail list logo
