Обсуждение: Re: [HACKERS] fsync method checking

Поиск
Список
Период
Сортировка

Re: [HACKERS] fsync method checking

От
markw@osdl.org
Дата:
On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>
>>markw@osdl.org writes:
>>
>>
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>>
>>>
>>
>>Just do some runs that are identical except for the wal_sync_method
>>setting.  Note that this should not have any impact on SELECT
>>performance, only insert/update/delete performance.
>>
>>
> I've made a test run that compares fsync and fdatasync: The performance
> was identical:
> - with fdatasync:
>
> http://khack.osdl.org/stp/290607/
>
> - with fsync:
> http://khack.osdl.org/stp/290483/
>
> I don't understand why. Mark - is there a battery backed write cache in
> the raid controller, or something similar that might skew the results?
> The test generates quite a lot of wal traffic - around 1.5 MB/sec.
> Perhaps the writes are so large that the added overhead of syncing the
> inode is not noticable?
> Is the pg_xlog directory on a seperate drive?
>
> Btw, it's possible to request such tests through the web-interface, see
> http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html

We have 2 Adaptec 2200s controllers, without the battery backed add-on,
connected to four 10-disk arrays in those systems.  I can't think of
anything off hand that would skew the results.

The pg_xlog directory is not on a separate drive.  I haven't found the
best way to lay out of the drives on those systems yet, so I just have
everything on a 28 drive lvm2 volume.

Mark

Re: [HACKERS] fsync method checking

От
Bruce Momjian
Дата:
markw@osdl.org wrote:
> > I've made a test run that compares fsync and fdatasync: The performance
> > was identical:
> > - with fdatasync:
> >
> > http://khack.osdl.org/stp/290607/
> >
> > - with fsync:
> > http://khack.osdl.org/stp/290483/
> >
> > I don't understand why. Mark - is there a battery backed write cache in
> > the raid controller, or something similar that might skew the results?
> > The test generates quite a lot of wal traffic - around 1.5 MB/sec.
> > Perhaps the writes are so large that the added overhead of syncing the
> > inode is not noticable?
> > Is the pg_xlog directory on a seperate drive?
> >
> > Btw, it's possible to request such tests through the web-interface, see
> > http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html
>
> We have 2 Adaptec 2200s controllers, without the battery backed add-on,
> connected to four 10-disk arrays in those systems.  I can't think of
> anything off hand that would skew the results.
>
> The pg_xlog directory is not on a separate drive.  I haven't found the
> best way to lay out of the drives on those systems yet, so I just have
> everything on a 28 drive lvm2 volume.

We don't actually extend the WAL file during writes (preallocated), and
the access/modification timestamp is only in seconds, so I wonder of the
OS only updates the inode once a second.  What else would change in the
inode more frequently than once a second?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: [HACKERS] fsync method checking

От
Josh Berkus
Дата:
Bruce,

> We don't actually extend the WAL file during writes (preallocated), and
> the access/modification timestamp is only in seconds, so I wonder of the
> OS only updates the inode once a second.  What else would change in the
> inode more frequently than once a second?

What about really big writes, when WAL files are getting added/recycled?

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco