Andreas, > - increase page size to 16kB (gbak -> and restore with new pagesize) > - increased buffers for firebird to use up to 4GB of ram (256kB) via gfix
With Classic server you *need* to reduce the number of cached pages -- I would recommend a value < 500 pages people keep telling me otherwise. Why would I not want firebird to fill up the cache with lots of pages? Am I misunderstanding firebirds buffer concept? <SL> There are 3 different ‘modes’ that Firebird can run in. <SL> “Classic” mode is for a large number of connections. For that mode, the number of pages needs to be reduced. <SL> For “SuperServer” and “SuperClassic” modes the number of pages can be maximized. why would it do that? It is entirely under our control when and if the server restarts or shuts down. I agree with the reasoning, I just don't see the scenario. Power outage would be the worst case scenario. And if that actually happened mid-transaction, we have nightly backups that would be good enough. Forced Writes = ON is HIGHLY recommended in all production use-cases. I realize that. The worst case scenario is acceptable to the client though. <SL> You must be in a unique environment. <SL> My clients/users would have my skin if I told them they had to redo all their work at 5pm, the end of a busy work day – just because I wanted to save “millisecond” for each write operation (given the presence of a RAID controller with battery cache) by using Forced Writes = Off and the power went out (someone bumped a power switch). > After all of this didn't really seem to do much, we had to pull out the big > guns: > Performance improved a bit, but still not the way we would like it to be. You should look at the fb_lock_print details, it is possible that you are experience issue with the external lock manager. Thanks for this information. I will check it out as soon as possible. Wasn't even aware there is a lock manager. Andreas Sean
