> While I really enjoy a SSD in my development machine, I have no real
> long-time experience with higher-prized enterprise class SSDs, but I
> guess you are using a normal consumer SSD?

Yes we used cheap SSD at the time when we decide to go this way.

>
> I'm not sure if I would use consumer SSDs as a host for Firebird
> databases at all. For sure not in a RAID with no TRIM support etc.
> Firebird is known to write very frequently e.g. on the transaction
> inventory page (TIP). So, even small, but a lot of writes are going on,
> which is a pretty serious scenario for the life-time and performance of
> a SSD. And due to similar life-time patterns, SSDs in a RAID might fail
> pretty much at the same time, although I don't have any real evidence
> for that.

Well my experience shows exactly what you say here. And that was my initial assumption for our problems recently.

That's why I initiated this thread here to see is there any way to lower the write operations to the SSD by caching changes in memory for longer period of time. Instead of ding write for each transaction to to that for 10 or even more transactions (all this depends on the rate transactions are completed)

That's why I asked the question what will be the impact of FW=OFF and by using other parameters to make sure that modified pages will be written after reaching specif number or after some time.

Are TIP bounded by same rules like other pages or they are always written on transaction completion?

>
> I would rather stay away from a SSD for Firebird databases and use fast
> HDDs instead. Ideally RAID 10 with a decent RAID controller and not one
> onboard of the motherboard. If you can't afford that and you need good
> write performance, I would at least separate the OS, the Firebird
> database and temp files onto separate disks.

In our configuration we use dmraid on Linux and it gives us decent performance for the size of the installation. We intend to change SSD with faster HDD when prices get back to normal levels. For example WD 10K 150GB.

>
> Possibly you can invest into more RAM and use a RAM disk with the extra
> RAM for hosting Firebird temp files.

System already has 8G RAM for what it does and is more then enough.

>
> A long-term test case with consumer SSDs hosting Firebird database would
> be interesting though. As I said, I have no real experience with using
> SSDs as server disks in production.

Our experience shows that consumer SSD is not a good choice for Firebird database. Maybe if there is good RAID controller with batter to protect it's cache and with enabled write caching this might help a little.