Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Greg Smith
Eduardo Piombino wrote: Postgres version: 8.2.4, with all defaults, except DateStyle and TimeZone. Ugh...there are several features in PostgreSQL 8.3 and later specifically to address the sort of issue you're running into. If you want to get good write performance out of this system, you may

Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Eduardo Piombino
Excellent, lots of useful information in your message. I will follow your advices, and keep you posted on any progress. I have yet to confirm you with some technical details of my setup, but I'm pretty sure you hit the nail in any case. One last question, this IO issue I'm facing, do you think it

Re: [PERFORM] [PERFORMANCE] work_mem vs temp files issue

2010-01-12 Thread Jaime Casanova
On Mon, Jan 11, 2010 at 3:18 PM, Tom Lane wrote: > > Hmm.  Not clear where the temp files are coming from, but it's *not* the > sort --- the "internal sort ended" line shows that that sort never went > to disk.  What kind of plan is feeding the sort node? > some time ago, you said: """ It might b

Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Craig Ringer
On 13/01/2010 1:47 PM, Eduardo Piombino wrote: I'm sorry. The server is a production server HP Proliant, I don't remember the exact model, but the key features were: 4 cores, over 2GHz each (I'm sorry I don't remember the actual specs), I think it had 16G of RAM (if that is possible?) It has two

Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Eduardo Piombino
I'm sorry. The server is a production server HP Proliant, I don't remember the exact model, but the key features were: 4 cores, over 2GHz each (I'm sorry I don't remember the actual specs), I think it had 16G of RAM (if that is possible?) It has two 320G disks in RAID (mirrored). I don't even hav

Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Craig Ringer
On 13/01/2010 12:59 PM, Eduardo Piombino wrote: My question then is: is there a way to limit the CPU assigned to a specific connection? I mean, I don't care if my ALTER TABLE takes 4 days instead of 4 hours. Something like: pg_set_max_cpu_usage(2/100); You're assuming the issue is CPU. I thin

Re: [PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Craig James
Eduardo Piombino wrote: Hi list, I'm having a problem when dealing with operations that asks too much CPU from the server. The scenario is this: A nice description below, but ... you give no information about your system: number of CPUs, disk types and configuration, how much memory, what hav

Re: [PERFORM] performance config help

2010-01-12 Thread Craig Ringer
On 13/01/2010 2:01 AM, Bob Dusek wrote: The connections to postgres are happening on the localhost. Our application server accepts connections from the network, and the application queries Postgres using a standard pg_pconnect on the localhost. Well, that's a good reason to have all those CPU

[PERFORM] a heavy duty operation on an "unused" table kills my server

2010-01-12 Thread Eduardo Piombino
Hi list, I'm having a problem when dealing with operations that asks too much CPU from the server. The scenario is this: I have a multithreaded server, each thread with its own connection to the database. Everything is working fine, actually great, actually outstandingly, in normal operation. I'v

Re: [PERFORM] performance config help

2010-01-12 Thread Matthew Wakeling
On Tue, 12 Jan 2010, Bob Dusek wrote: Each of the concurrent clients does a series of selects, inserts, updates, and deletes. The requests would generally never update or delete the same rows in a table. However, the requests do generally write to the same tables. And, they are all reading fro

Re: [PERFORM] performance config help

2010-01-12 Thread Bob Dusek
> Bob, you might want to just send plain text, to avoid such problems. Will do. Looks like gmail's interface does it nicely. > > -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-p

Re: [PERFORM] performance config help

2010-01-12 Thread Bob Dusek
On Tue, Jan 12, 2010 at 12:12 PM, Matthew Wakeling wrote: > On Mon, 11 Jan 2010, Bob Dusek wrote: > >> How do I learn more about the actual lock contention in my db? Lock >> contention makes >> some sense. Each of the 256 requests are relatively similar. So, I don't >> doubt that >> lock conte

Re: [PERFORM] performance config help

2010-01-12 Thread Kevin Grittner
Matthew Wakeling wrote: >> -Kevin > > It'd really help us reading your emails if you could make sure > that it is easy to distinguish your words from words you are > quoting. It can be very confusing reading some of your emails, > trying to remember which bits I have seen before written b

Re: [PERFORM] performance config help

2010-01-12 Thread Matthew Wakeling
On Mon, 11 Jan 2010, Bob Dusek wrote: How do I learn more about the actual lock contention in my db?   Lock contention makes some sense.  Each of the 256 requests are relatively similar.  So, I don't doubt that lock contention could be an issue.  I just don't know how to observe it or correct