Two suggestions..
1. Patch linux kernel for HT aware scheduler.
2. Try running Xeons in HTdisabled modes.
See if that helps. I would say using 2.6 on it is recommended anyways.. If
possible of course..
I would avoid 2.6 on a production machine. 2.6 breaks alot (not as in a
bad thing
On Saturday 20 December 2003 00:00, Josh Berkus wrote:
> In discussions with Linux kernel hackers online, they blame the way that
> PostgreSQL uses shared memory. Whether or not they are correct, the
> effect of the issue is to harm PostgreSQL's performance and make us look
> bad on one of the ma
On Fri, Dec 19, 2003 at 11:17:31AM -0800, Josh Berkus wrote:
>
> Important fact left out of the problem description: The issue happens when
> *two or more* intensive queries are running simultaneosly.
So two queries are enough to get this problem?
I assume the tables are so big that they don't
Josh Berkus wrote:
Initial debug logging of a test on one Xeon system demonstrating this issue
showed a very large number of unattributed semop() calls. We are still
following up on this.
Postgres has it's own user space spinlock and semaphore implementation.
Both fall back to semop if ther
Kurt,
> This is without any other query running, right? I even find 5000
> cs/s rather large if there isn't any other process that wants
> some CPU.
Sorry! Darn!
Important fact left out of the problem description: The issue happens when
*two or more* intensive queries are running simultaneo
On Fri, Dec 19, 2003 at 10:30:13AM -0800, Josh Berkus wrote:
>
> Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22
> Not tested on other distros/kernels. Kernels are SMP-enabled.
Does the same problem show with an SMP kernel on an UP system?
> When a query is
Folks,
I brought up this issue a couple of weeks ago on the Performance list. Since
then, I've gotten e-mail confirmation from a few other users seeing this
problem. Here's the shape of the problem, we just don't know what causes it.
I've been trying to do some profiling, but since I only ha
