[PERFORM] Toooo many context switches (maybe SLES8?)

2004-04-15 Thread Dirk Lutzebäck
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

Re: [PERFORM] Toooo many context switches (maybe SLES8?)

2004-04-15 Thread Dirk Lutzebäck
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

RESOLVED: Re: [PERFORM] Wierd context-switching issue on Xeon

2004-04-16 Thread Dirk Lutzebäck
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

Re: RESOLVED: Re: [PERFORM] Wierd context-switching issue on Xeon

2004-04-19 Thread Dirk Lutzebäck
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

Re: [PERFORM] Wierd context-switching issue on Xeon

2004-04-20 Thread Dirk Lutzebäck
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..

[PERFORM] SURVEY: who is running postgresql on 8 or more CPUs?

2005-05-31 Thread Dirk Lutzebäck
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

Re: [PERFORM] SURVEY: who is running postgresql on 8 or more CPUs?

2005-06-02 Thread Dirk Lutzebäck
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

Re: [PERFORM] SURVEY: who is running postgresql on 8 or more CPUs?

2005-06-02 Thread Dirk Lutzebäck
? 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

[PERFORM] Optimizer seems to be way off, why?

2005-07-20 Thread Dirk Lutzebäck
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

Re: [PERFORM] Optimizer seems to be way off, why?

2005-07-20 Thread Dirk Lutzebäck
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

[PERFORM] Performance problems on 4/8way Opteron (dualcore) HP DL585

2005-07-29 Thread Dirk Lutzebäck
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

Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-31 Thread Dirk Lutzebäck
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

Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-31 Thread Dirk Lutzebäck
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.

[PERFORM] Performance problems on 4-way AMD Opteron 875 (dual core)

2005-08-05 Thread Dirk Lutzebäck
[[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

Re: [PERFORM] query produces 1 GB temp file

2006-10-27 Thread Dirk Lutzebäck
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