|Subject||Re: [firebird-support] Firebird 2.5 classic performance issue on linux64|
first off, thanks for the quick response. answers below.
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?
> - 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
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.
> - 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.
I realize that. The worst case scenario is acceptable to the client though.
Forced Writes = ON is HIGHLY recommended in all production use-cases.
Thanks for this information. I will check it out as soon as possible. Wasn't even aware there is a lock manager.
> 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.