On the context switching issue, we've found that this setting in /etc/system helps:
set rechoose_interval=30
this sets the minimum time that a process is eligible to be switched to another cpu. (the default is 3).
You can monitor context switching with the cs column in vmstat. We've found that high context switching seems to be more a symptom, rather than a cause of problems -- for example we had an issue with column statistics and some really bad queries, and the cpu's start context switching like crazy. (20,000 - 50,000 or more in a 5 second period, normally < 5000 per 5 second period under heavy load.)
Brandon Metcalf wrote:
a == [EMAIL PROTECTED] writes:
a> On Tue, Mar 22, 2005 at 03:23:18PM -0600, Brandon Metcalf wrote: a> > s> What are you using to measure a> > s> performance? a> > a> > Nothing too scientific other than the fact that since we have moved a> > the DB, we consistenly see a large number of postmater processes a> > (close to 100) where before we did not.
a> What did you move from? The Solaris ps (not in ucb, which is the a> BSD-style ps) shows the parent process name, so everything shows up a> as "postmaster" rather than "postgres". There's always one back end a> per connection.
a> If you are in fact using more connections, by the way, I can tell you a> that Solaris 8, in my experience, is _very bad_ at managing context a> switches. So you may not be merely I/O bound (although your other a> reports seem to indicate that you are).
We moved from an HP-UX 10.20 box where the pgsql installation and data were on a vxfs fileystem.
And we're definitely seeing more connections at a time which indicates that each process is taking longer to complete.
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
