Jignesh,
> Don't get me wrong. As Luke mentioned it took a while to get the
> potential of PostgreSQL on Solaris and people like me start doing other
> complex workarounds in Solaris like "forcedirectio", etc. (Yeah I did a
> test, if you force fsync as wal_sync_method while on Solaris, then
>
Hi Bruce,
I saw even on this alias also that people assumed that the default
wal_sync_method was fsync on Solaris.
I would select fsync or fdsync as the default on Solaris. (I prefer
fsync as it is already highlighted as default in postgresql)
Another thing to improve the defaults on Solar
On 4/12/06, Josh Berkus wrote:
> People,
>
> > Lately I find people are not so receptive to VxFS, and Sun is promoting
> > ZFS, and we don't have a reasonable near term option for Raw IO in
> > Postgres, so we need to work to find a reasonable path for Solaris users
> > IMO. The long delays in ZFS
Bruce Momjian wrote On 04/13/06 01:39 AM,:
>
> Yes, if someone wants to give us a clear answer on which wal_sync method
> is best on all versions of Solaris, we can easily make that change.
>
We're doing tests to see how various parameters in postgresql.conf
affect performance on Solaris and wi
Jignesh K. Shah wrote:
>
> Bruce,
>
> Hard to answer that... People like me who know and love PostgreSQL and
> Solaris finds this as an opportunity to make their favorite database
> work best on their favorite operating system.
>
> Many times PostgreSQL has many things based on assumption tha
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Many times PostgreSQL has many things based on assumption that it will
> run on Linux and it is left to Solaris to emulate that behavior.
Au contraire --- PG tries its best to be OS-agnostic. I've personally
resisted people trying to optimize it b
Bruce,
Hard to answer that... People like me who know and love PostgreSQL and
Solaris finds this as an opportunity to make their favorite database
work best on their favorite operating system.
Many times PostgreSQL has many things based on assumption that it will
run on Linux and it is le
People,
> Lately I find people are not so receptive to VxFS, and Sun is promoting
> ZFS, and we don't have a reasonable near term option for Raw IO in
> Postgres, so we need to work to find a reasonable path for Solaris users
> IMO. The long delays in ZFS production haven't helped us there, as th
Bruce,
On 4/12/06 12:56 PM, "Bruce Momjian" wrote:
> It is hard to imagine why people spend so much time modifying Sun
> machines run with acceptable performance when non-Sun operating systems
> work fine without such hurtles.
There are a lot of Solaris customers that we support and that we'd l
Luke Lonergan wrote:
> Alvaro,
>
> On 4/5/06 2:48 PM, "Alvaro Herrera" <[EMAIL PROTECTED]> wrote:
>
> > This essentially means stopping all bgwriter activity, thereby deferring
> > all I/O until checkpoint. Was this considered? With
> > checkpoint_segments to 128, it wouldn't surprise me that t
> > Chris,
> > Just to make sure the x4100 config is similar to your Linux system, can
> > you verify the default setting for disk write cache and make sure they
> > are both enabled or disabled. Here's how to check in Solaris.
> > As root, run "format -e" -> pick a disk -> cache -> write_cache
> >Ok, so I did a few runs for each of the sync methods, keeping all the
> >rest constant and got this:
> >
> >open_datasync 0.7
> >fdatasync 4.6
> >fsync 4.5
> >fsync_writethrough not supported
> >open_sync 0.6
> >
> >in arbitrary units - higher is faster.
> >
Chris Mair wrote:
Ok, so I did a few runs for each of the sync methods, keeping all the
rest constant and got this:
open_datasync 0.7
fdatasync 4.6
fsync 4.5
fsync_writethrough not supported
open_sync 0.6
in arbitrary units - higher is faster.
Quite impress
Mark, Chris,
> Yeah - looks good! (is the default open_datasync still?). Might be worth
> trying out the fdatasync method too (ISTR this being quite good... again
> on Solaris 8, so things might have changed)!
I was just talking to a member of the Solaris-UFS team who recommended that we
test fd
Chris,
> Remounting the fs where $PGDATA lives with "forcedirectio"
> (together with logging, that is default) did not help
> (if not harm...) performance.
Not all of PG. JUST pg_xlog. forcedirectio is only a good idea for the xlog.
> Quickly playing around with wal_buffers on Linux and Mac OS
Chris,
On 4/5/06 2:31 PM, "Chris Mair" <[EMAIL PROTECTED]> wrote:
> Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> wal_sync_method = fsync (unchanged)
> wal_buffers = 128 (was 8)
> checkpoint_segments = 128 (was 3)
> bgwriter_all_percent = 0 (was 0.333)
> bgwriter_all_ma
> > Yeah - looks good! (is the default open_datasync still?). Might be worth
> > trying out the fdatasync method too (ISTR this being quite good... again
> > on Solaris 8, so things might have changed)!
>
> I was just talking to a member of the Solaris-UFS team who recommended that
> we
> test
Hi,
thanks for all replys.
I've done a few tests.
Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.
Doing what http://blogs.sun.com/roller/page/jkshah suggests:
wal_sync_method = fsync (unchanged)
w
Chris Mair wrote:
(but note the other mail about wal_sync_method = fsync)
Yeah - looks good! (is the default open_datasync still?). Might be worth
trying out the fdatasync method too (ISTR this being quite good... again
on Solaris 8, so things might have changed)!
Cheers
Mark
> > I've done a few tests.
> >
> > Remounting the fs where $PGDATA lives with "forcedirectio"
> > (together with logging, that is default) did not help
> > (if not harm...) performance.
> >
> >
>
> Sure - forcedirectio on the entire $PGDATA is a definite loss, you only
> want it on $PGDATA/pg_
Alvaro,
On 4/5/06 2:48 PM, "Alvaro Herrera" <[EMAIL PROTECTED]> wrote:
> This essentially means stopping all bgwriter activity, thereby deferring
> all I/O until checkpoint. Was this considered? With
> checkpoint_segments to 128, it wouldn't surprise me that there wasn't
> any checkpoint execut
appears this didn't make it to the list... resending to the list
directly...
---
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent =
Chris Mair wrote:
Hi,
thanks for all replys.
I've done a few tests.
Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.
Sure - forcedirectio on the entire $PGDATA is a definite loss, you only
want i
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent = 0 (was 0.333)
> > > bgwriter_all_maxpages = 0 (was 5)
> > > and leaving everyt
Luke Lonergan wrote:
> Chris,
>
> On 4/5/06 2:31 PM, "Chris Mair" <[EMAIL PROTECTED]> wrote:
>
> > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > wal_sync_method = fsync (unchanged)
> > wal_buffers = 128 (was 8)
> > checkpoint_segments = 128 (was 3)
> > bgwriter_all_perc
Mark,
> I suspect that making a *separate* filesystem for the pg_xlog directory
> and mounting that logging + forcedirectio would be a nice way to also
> get performance while keeping the advantages of logging + file
> buffercache for the *rest* of the postgres components.
> Cheers
Yes, we tested
Chris Mair wrote:
Hi,
I've got a somewhat puzzling performance problem here.
I'm trying to do a few tests with PostgreSQL 8.1.3 under Solaris
(an OS I'm sort of a newbie in).
The machine is a X4100 and the OS is Solaris 10 1/06 fresh install
according to manual. It's got two SAS disks in RAID
Title: Re: [PERFORM] bad performance on Solaris 10
Jignesh’s blog has some of the good stuff in it:
http://blogs.sun.com/roller/page/jkshah
- Luke
On 4/3/06 5:49 PM, "Josh Berkus" wrote:
Chris,
> Eons ago PCs had those "turbo" switches (it was never totally cl
Chris,
> Eons ago PCs had those "turbo" switches (it was never totally clear
> why they put them there in the first place, anyway). I've this bad
> feeling there's a secret "turbo" switch I can't spot hidden somewhere
> in Solaris :/
Yes. Check out Jignesh's configuration advice ach, this
Hi,
I've got a somewhat puzzling performance problem here.
I'm trying to do a few tests with PostgreSQL 8.1.3 under Solaris
(an OS I'm sort of a newbie in).
The machine is a X4100 and the OS is Solaris 10 1/06 fresh install
according to manual. It's got two SAS disks in RAID 1, 4GB of RAM.
Now
30 matches
Mail list logo
