Hi Sean,

first off, thanks for the quick response. answers below.

 

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?

> - switchted to async writes because we have redundancy and data security
> on hardware level (also via gfix)

Hardware redundancy and security will not protect if the hosts/OS restarts or Firebird abends without warning.

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.

> 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