On Mon, Aug 16, 2010 at 01:46:21PM -0400, Greg Smith wrote: > Scott Carey wrote: > >This is because an fsync on ext3 flushes _all dirty pages in the file > >system_ to disk, not just those for the file being fsync'd. > >One partition for WAL, one for data. If using ext3 this is > >essentially a performance requirement no matter how your array is > >set up underneath. > > Unless you want the opposite of course. Some systems split out the > WAL onto a second disk, only to discover checkpoint I/O spikes > become a problem all of the sudden after that. The fsync calls for > the WAL writes keep the write cache for the data writes from ever > getting too big. This slows things down on average, but makes the > worst case less stressful. Free lunches are so hard to find > nowadays... Or use -o sync. Or configure a ridiciuosly low dirty_memory amount (which has a problem on large systems because 1% can still be too much. Argh.)...
Andres -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
