Hi,

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.

Regards,
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64