I just wanted to follow up and let everyone know that the biggest
improvement in performance came from moving the pg_xlog directory to
another filesystem (different set of disks) separate from the data
directory.
Thanks for the suggestions.
--
Brandon
---(end of broadcas
Andrew,
> The Packer Solaris database book (Packer, Allan N., _Configuring &
> Tuning Databases on the Solaris Platform_. Palo Alto: Sun
> Microsystems P, 2002. ISBN 0-13-083417-3) does suggest mounting the
> filesystems with forcedirectio; I dimly recall using this for the wal
> partition on on
On Wed, Mar 23, 2005 at 09:32:07AM -0800, Tom Arthurs wrote:
> found that high context switching seems to be more a symptom,
Yes, that's a good point. It usually _is_ a symptom; but it might be
a symptom that you've got an expensive query, and Solaris's foot-gun
approach to handling such cases is
On Wed, Mar 23, 2005 at 11:16:29AM -0600, Brandon Metcalf wrote:
>
> We moved from an HP-UX 10.20 box where the pgsql installation and data
> were on a vxfs fileystem.
My best guess, then, is that ufs tuning really is your issue. We
always used vxfs for our Sun database servers (which was a nigh
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
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 post
On Tue, Mar 22, 2005 at 03:23:18PM -0600, Brandon Metcalf wrote:
> s> What are you using to measure
> s> performance?
>
> Nothing too scientific other than the fact that since we have moved
> the DB, we consistenly see a large number of postmater processes
> (close to 100) where before we did no
Brandon Metcalf wrote:
We've recently moved our pgsql installation and DBs to a Solaris 8
machine with striped and mirrored ufs filesystem that houses the DB
data. We are now seeing terrible performance and the bottleneck is no
doubt disk I/O.
We've tried modifying a tunables related to ufs, but i
s == [EMAIL PROTECTED] writes:
s> What are you using to create your raid?
Hm. I didn't set this up. I'll have to check.
s> You say it is "no doubt disk
s> I/O" - does iostat confirm this? A lot of performance issues are related
s> to the size of the stripe you chose for the striped portion
s == [EMAIL PROTECTED] writes:
s> Try setting
s> set ufs:ufs_WRITES=0
s> in /etc/system and rebooting, which basically says "any amount of disk
s> IO can be outstanding". There's a tunables doc on docs.sun.com that
s> explains this option.
s> Also, logging UFS might help with some of the m
Brandon Metcalf wrote:
We've recently moved our pgsql installation and DBs to a Solaris 8
machine with striped and mirrored ufs filesystem that houses the DB
data. We are now seeing terrible performance and the bottleneck is no
doubt disk I/O.
We've tried modifying a tunables related to ufs, but i
On Tue, 2005-03-22 at 14:44 -0600, Brandon Metcalf wrote:
> We've recently moved our pgsql installation and DBs to a Solaris 8
> machine with striped and mirrored ufs filesystem that houses the DB
> data. We are now seeing terrible performance and the bottleneck is no
> doubt disk I/O.
>
> We've
We've recently moved our pgsql installation and DBs to a Solaris 8
machine with striped and mirrored ufs filesystem that houses the DB
data. We are now seeing terrible performance and the bottleneck is no
doubt disk I/O.
We've tried modifying a tunables related to ufs, but it doesn't seem
to be h
13 matches
Mail list logo
