On 3/16/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Can you try strace'ing some of the backend processes while the system is
> behaving like this? I suspect what you'll find is a whole lot of
> delaying select() calls due to high contention for spinlocks ...
As announced, we have migrated our produ
On Thu, Mar 16, 2006 at 11:45:12AM +0100, Guillaume Smet wrote:
> Hello,
>
> We are experiencing performances problem with a quad Xeon MP and
> PostgreSQL 7.4 for a year now. Our context switch rate is not so high
> but the load of the server is blocked to 4 even on very high load and
> we have 60
On 3/16/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> What we want to find out is if there's a lot of select()s and/or
> semop()s shown in the result. Ideally there wouldn't be any, but
> I fear that's not what you'll find.
OK, I'll try to do it on monday before our upgrade then see what
happens with
Hi Guillaume,
Guillaume Smet schrieb:
How much faster is the XEON DP?
Well, on high load, PostgreSQL scales well on the DP (load at 40,
queries slower but still performing well) and is awfully slow on the
MP box.
I know what you mean with awfully slow.
I think, your application is facing con
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> You mean strace -p pid with pid on some of the postgres process not on
> the postmaster itself, does you?
Right, pick a couple that are accumulating CPU time.
> Do we need other options?
strace will generate a *whole lot* of output to stderr. I usu
On 3/16/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Can you try strace'ing some of the backend processes while the system is
> behaving like this? I suspect what you'll find is a whole lot of
> delaying select() calls due to high contention for spinlocks ...
Tom,
I think we can try to do it.
You
On 3/16/06, Sven Geisler <[EMAIL PROTECTED]> wrote:
> Did you compare 7.4 on a 4-way with 8.1 on a 2-way?
I know there are too many parameters changing between the two servers
but I can't really change anything before tuesday. On tuesday, we will
be able to compare both servers with the same softw
Hi Guillaume,
Guillaume Smet schrieb:
The server is a dell 6650 from end of 2004 with 4 xeon mp 2.2 and 2MB
cache per proc.
Here are the information from Dell:
4x PROCESSOR, 80532, 2.2GHZ, 2MB cache, 400Mhz, SOCKET F
8x DUAL IN-LINE MEMORY MODULE, 512MB, 266MHz
You should provide det
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Here is a top output I had on november 17 when the server completely
> hangs (several minutes for each page of the website) and it is typical
> of this server behaviour:
> 17:08:41 up 19 days, 15:16, 1 user, load average: 4.03, 4.26, 4.36
> 288 proc
On 3/16/06, Sven Geisler <[EMAIL PROTECTED]> wrote:
> Hi Guillaume,
>
> I had a similar issue last summer. Could you please provide details
> about your XEON MP server and some statistics (context-switches/load/CPU
> usage)?
I forgot the statistics:
CPU load usually from 1 to 4.
CPU usage < 40% fo
Sven,
On 3/16/06, Sven Geisler <[EMAIL PROTECTED]> wrote:
> What version of XEON MP does your server have?
The server is a dell 6650 from end of 2004 with 4 xeon mp 2.2 and 2MB
cache per proc.
Here are the information from Dell:
4x PROCESSOR, 80532, 2.2GHZ, 2MB cache, 400Mhz, SOCKET F
8x DUAL IN
On 3/16/06, Richard Huxton wrote:
> Very strange.
Sure. I can't find any logical explanation for that but it is the
behaviour we have for more than a year now (the site was migrated from
Oracle to PostgreSQL on january 2005).
We check iostat, vmstat and so on without any hint on why we have this
Guillaume Smet wrote:
Richard,
You should be seeing context-switching jump dramatically if it's the
"classic" multi-Xeon problem. There's a point at which it seems to just
escalate without a corresponding jump in activity.
No we don't have this problem of very high context switching in our
ca
Hi Guillaume,
I had a similar issue last summer. Could you please provide details
about your XEON MP server and some statistics (context-switches/load/CPU
usage)?
I tried different servers (x86) with different results. I saw a
difference between XEON MP w/ and w/o EMT64. The memory bandwidth
Richard,
> You should be seeing context-switching jump dramatically if it's the
> "classic" multi-Xeon problem. There's a point at which it seems to just
> escalate without a corresponding jump in activity.
No we don't have this problem of very high context switching in our
case even when the dat
Guillaume Smet wrote:
Hello,
We are experiencing performances problem with a quad Xeon MP and
PostgreSQL 7.4 for a year now.
I had a similar issue with a client the other week.
Our context switch rate is not so high
but the load of the server is blocked to 4 even on very high load and
we ha
Hello,
We are experiencing performances problem with a quad Xeon MP and
PostgreSQL 7.4 for a year now. Our context switch rate is not so high
but the load of the server is blocked to 4 even on very high load and
we have 60% cpu idle even in this case. Our database fits in RAM and
we don't have any
17 matches
Mail list logo
