And here are results of built-in Postgres test script:
Simple write timing:
write 0.006355
Compare fsync times on write() and non-write() descriptor:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close 0.233793
write, close, fsync 0.227444
Compare one o_sync write to two:
one 16k o_sync write 0.297093
two 8k o_sync writes 0.402803
Compare file sync methods with one 8k write:
(o_dsync unavailable)
write, fdatasync 0.228725
write, fsync, 0.223302
Compare file sync methods with 2 8k writes:
(o_dsync unavailable)
open o_sync, write 0.414954
write, fdatasync 0.335280
write, fsync, 0.327195
(Also, I tried to manually specify open_sync method in postgresql.conf, but
after that Postgres database had completely crashed. :-)
On 8/22/07, Dmitry Koterov <[EMAIL PROTECTED] > wrote:
>
> All settings seems to be fine. Mode is writeback.
>
> We temporarily (for tests only on test machine!!!) put pg_xlog into RAM
> drive (to completely exclude xlog fsync from the statistics), but slowdown
> during the checkpoint and 5-10 second fsync during the checkpoint are alive
> yet.
>
> Here are some statistical data from the controller. Other report data is
> attached to the mail.
>
> ACCELERATOR STATUS:
> Logical Drive Disable Map: 0x00000000
> Read Cache Size: 24 MBytes
> Posted Write Size: 72 MBytes
> Disable Flag: 0x00
> Status: 0x00000001
> Disable Code: 0x0000
> Total Memory Size: 128 MBytes
> Battery Count: 1
> Battery Status: 0x0001
> Parity Read Errors: 0000
> Parity Write Errors: 0000
> Error Log: N/A
> Failed Batteries: 0x0000
> Board Present: Yes
> Accelerator Failure Map: 0x00000000
> Max Error Log Entries: 12
> NVRAM Load Status: 0x00
> Memory Size Shift Factor: 0x0a
> Non Battery Backed Memory: 0 MBytes
> Memory State: 0x00
>
>
> On 8/22/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> >
> > On 8/22/07, Dmitry Koterov <[EMAIL PROTECTED]> wrote:
> > > Hello.
> > > You see, 50M block was fsynced for 0.25 s.
> > >
> > > The question is: how to solve this problem and make fsync run with no
> > delay.
> > > Seems to me that controller's internal write cache is not used
> > (strange,
> > > because all configuration options are fine), but how to check it? Or,
> > maybe,
> > > there is another side-effect?
> >
> > I would suggest that either the controller is NOT configured fine, OR
> > there's some bug in how the OS is interacting with it.
> >
> > What options are there for this RAID controller, and what are they set
> > to? Specifically, the writeback / writethru type options for the
> > cache, and it might be if it doesn't preoprly detect a battery backup
> > module it refuses to go into writeback mode.
> >
>
>
>
