Hello Kjell,

> From this list and other places I have grown used to always setting my
> FB databases to use forced writes, in order to avoid database corruption
> should the system shutdown unexpectedly, e.g. due to power loss.
>
> I have recently had an experience that has led to me to reevaluate this,
> and thought I would share it.
>
> I have an ECO + ASP.Net based system running on a dedicated Windows 2008
> web 64 bit server with 8 Gbyte RAM and fast SCSI disks with RAID 1
> mirroring. Firebird 2.1 64 bit in classic mode. 8 kernels in the CPU.
>
> The application has a large and somewhat complicated form that our users
> update, save, goto next record, etc.
>
> With the original setup, the save/goto next cycle usually took about 20
> seconds.
>
> In an attempt to improve things, I bumped up to 16 Gbyte RAM and a
> substantially larger page cache. I had it set to default 75 pages (8192
> byte/page). I bumped it up to as much as 64k page buffers, causing each
> connection to use up half a Gbyte of memory. These two changes had
> limited effect - I think the save/next cycle dropped to about 15 seconds.
>
> Then I tried to switch forced writes off.
>
> Wow!!!
>
> Now, suddenly it takes no more than 2-3 seconds!
>
> I can also see with Sinática Monitor that the transaction curve has
> changed character from a smooth diagonal line indicating a even number
> of transactions/second, to a wobbly and jagged line with several sharp
> vertical edges, indicating that there are bursts of very many commits.
>
> Thinking back, I have always thought that FB seems to do a LOT of disk
> head seeks on EACH commit. No wonder it can only handle a few commits
> per second, even on fast disks.
>
> So, from now on, when performance matters, I am going to switch forced
> wtites off. Yes, off.
>
> The corruption risk is handled by backup and hardware means. Our
> dedicated server is located in a place where they have significant spare
> power. Mirrored disks protects aginst most hard disk failures. Regular
> backups makes the protection scheme complete.
>
> Please note that this system is not of a 24/7 kind, and neither is it
> vital to avoid loss of data since last backup, assuming the backup is
> fresh enough. If such requirements exist, further measures have to be
> taken, e.g. power backup on the disk controllers and replication.

For using a database with forced writes = off, you may also consider
tweaking the following parameters in firebird.conf:

MaxUnflushedWrites
MaxUnflushedWriteTime

This more or less allows you to specify some kind of flush cycle, so
that things are written to disk, even if forced writes = off.



--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!