Yeah, I'm sure binding each process to a CPU would be a significant help. Something I've always wanted to quantify but haven't made time for...


Luke Lonergan wrote:
One of our customers noticed that there were a high number of NUMA cache
misses on a quad core opteron system running Bizgres MPP resulting in about
a 15% performance hit.  We use a process-based parallelization approach and
we can guess that there's context switching due to the high degree of
pipeline parallelism in our executions plans.  Each context switch likely
switches a process away from the CPU with local memory, resulting in the
NUMA cache misses.

The answer for us is to bind each process to a CPU.  Might that help in
running DBT-2?

- Luke

On 10/10/06 9:40 AM, "Mark Wong" <[EMAIL PROTECTED]> wrote:

Luke Lonergan wrote:

Mark, can you quantify the impact of not running with IRQ balancing enabled?
Whoops, look like performance was due more to enabling the
--enable-thread-safe flag.

IRQ balancing on : 7086.75
IRQ balancing off: 7057.90

The interrupt charts look completely different.  There's too much stuff
on the chart to determine what interrupts are from what though. :(  It
needs to be redone per processor (as opposed to per interrupt per
processor) to be more useful in determining if one processor is
overloaded due to interrupts.

But the sum of all the interrupts handled are close between tests so it
seems clear no single processor was overloaded:


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to