Hi,
we have a complex modperl database application using postgresql 7.4.1 on
a new Dual Xeon MP Machine with SLES8 which seems to generate too much
context switches (way more than 100.000) on higher load (meaning system
load 2). System response times significantly slow down then. We have
Joe, do you know where I should look in the 7.4.2 code to find this out?
Dirk
Joe Conway wrote:
Dirk Lutzebäck wrote:
postgresql 7.4.1
a new Dual Xeon MP
too much context switches (way more than 100.000) on higher load
(meaning system load 2).
I believe this was fixed in 7.4.2, although
Tom, Josh,
I think we have the problem resolved after I found the following note
from Tom:
A large number of semops may mean that you have excessive contention
on some lockable
resource, but I don't have enough info to guess what resource.
This was the key to look at: we were missing all
Josh, I cannot reproduce the excessive semop() on a Dual XEON DP on a
non-bigmem kernel, HT on. Interesting to know if the problem is related
to XEON MP (as Tom wrote) or bigmem.
Josh Berkus wrote:
Dirk,
I'm not sure if this semop() problem is still an issue but the database
behaves a bit
Dirk Lutzebaeck wrote:
c) Dual XEON DP, non-bigmem, HT on, E7500 Intel chipset (Supermicro)
performs well and I could not observe context switch peaks here (one
user active), almost no extra semop calls
Did Tom's test here: with 2 processes I'll reach 200k+ CS with peaks to
300k CS. Bummer..
Hi,
I would like to start a little survey who is running postgresql on an
8way or more machine (Intel, Sparc, AMD no matter). Purpose: find out
how postgresql runs in high performance areas.
Please fillout:
Machine (Vendor, Product):
Architecture (Intel/Sparc/AMD/IBM):
Processors
Hi,
I just got one reply for this survey. Is almost nobody using postgresql
on 8+ machines?
Regards,
Dirk
Dirk Lutzebäck wrote:
Hi,
I would like to start a little survey who is running postgresql on an
8way or more machine (Intel, Sparc, AMD no matter). Purpose: find out
how postgresql
? Who did it?
Regards,
Dirk
Dawid Kuroczko wrote:
On 6/2/05, Dirk Lutzebäck [EMAIL PROTECTED] wrote:
I just got one reply for this survey. Is almost nobody using postgresql
on 8+ machines?
My guess is when someone is using PostgreSQL on 8+ machine, she's
in highly competitive
Hi,
I do not under stand the following explain output (pgsql 8.0.3):
explain analyze
select b.e from b, d
where b.r=516081780 and b.c=513652057 and b.e=d.e;
QUERY PLAN
Richard Huxton wrote:
Dirk Lutzebäck wrote:
Hi,
I do not under stand the following explain output (pgsql 8.0.3):
explain analyze
select b.e from b, d
where b.r=516081780 and b.c=513652057 and b.e=d.e;
QUERY PLAN
Hi,
does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)? We run RHEL 3.0, 32bit and under high load it is a drag. We
mostly run memory demanding queries. Context switches are pretty much
around 20.000 on the average, no cs spikes when we run many processes in
Anybody knows if RedHat is already supporting this patch on an
enterprise version?
Regards,
Dirk
J. Andrew Rogers wrote:
On 7/29/05 10:46 AM, Josh Berkus josh@agliodbs.com wrote:
does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)?
Nope. I suspect that you
Hi Jeff,
which box are you running precisely and which OS/kernel?
We need to run 32bit because we need failover to 32 bit XEON system
(DL580). If this does not work out we probably need to switch to 64 bit
(dump/restore) and run a nother 64bit failover box too.
Regards,
Dirk
Jeffrey W.
[[I'm
posting this on behalf of my co-worker who cannot post to this list at
the moment]]
Hi,
I had installed PostgreSQL on a 4-way AMD Opteron 875 (dual core) and
the performance isn't on the expected level.
Details:
The "old" server is a 4-way XEON MP 3.0 GHz with 4MB L3 cache, 32 GB
Hi,
I'm sorry but it look like my computer has resent older posts from me,
sigh...
Dirk
Alexander Staubo wrote:
While I can't explain why PostgreSQL would use that
memory, I recommend looking into tweaking the work_mem parameter. This
setting specifies how much memory PostgreSQL on certain
15 matches
Mail list logo