Subject | Re: Forced writes off on Windows? |
---|---|
Author | nathanelrick |
Post date | 2012-03-10T06:41:04Z |
hello,
in the firebird.conf you have this 2 params :
# ----------------------------
#
# How often the pages are flushed on disk
# (for databases with ForcedWrites=Off only)
#
# Number of unflushed writes which will accumulate before they are
# flushed, at the next transaction commit. For non-Win32 ports,
# the default value is -1 (Disabled)
#
# Type: integer
#
#MaxUnflushedWrites = 100
#
# Number of seconds during which unflushed writes will accumulate
# before they are flushed, at the next transaction commit. For non-Win32
# ports, the default value is -1 (Disabled)
#
# Type: integer
#
#MaxUnflushedWriteTime = 5
that mean the flush to the disk of the page in the cache will be done every 5 secondes. as you can read : "at the next transaction commit" that mean that an unlucky user that will do commit, during his commit all the data will be flush so his commit will be slow because he will flush also the data of all other commit in the cache. on some particular commit (mostly that update lot of indexes) this is not negligeable at all ! i see some case where the commit in the cache cost 0 ms, but the unlucky commit that flush the cache to disk cost 5 secondes !
for my point of view, i think it's better to keep force write on but to have the flush to disc mecanisme on the raid controller (mostly the 256 mb cache + battery that keep the cache for +72 hours in case of system shuntdown). but i never do any bench
in the firebird.conf you have this 2 params :
# ----------------------------
#
# How often the pages are flushed on disk
# (for databases with ForcedWrites=Off only)
#
# Number of unflushed writes which will accumulate before they are
# flushed, at the next transaction commit. For non-Win32 ports,
# the default value is -1 (Disabled)
#
# Type: integer
#
#MaxUnflushedWrites = 100
#
# Number of seconds during which unflushed writes will accumulate
# before they are flushed, at the next transaction commit. For non-Win32
# ports, the default value is -1 (Disabled)
#
# Type: integer
#
#MaxUnflushedWriteTime = 5
that mean the flush to the disk of the page in the cache will be done every 5 secondes. as you can read : "at the next transaction commit" that mean that an unlucky user that will do commit, during his commit all the data will be flush so his commit will be slow because he will flush also the data of all other commit in the cache. on some particular commit (mostly that update lot of indexes) this is not negligeable at all ! i see some case where the commit in the cache cost 0 ms, but the unlucky commit that flush the cache to disk cost 5 secondes !
for my point of view, i think it's better to keep force write on but to have the flush to disc mecanisme on the raid controller (mostly the 256 mb cache + battery that keep the cache for +72 hours in case of system shuntdown). but i never do any bench