| Subject | Re: [firebird-support] High CPU use after restore |
|---|---|
| Author | Carlos H. Cantu |
| Post date | 2015-10-27T23:53:59Z |
1) Upgrade to 2.5.4 (this will solve dumb Windows cache eating memory and causing swap problem)
2) Make sure to not have ran the -fix_* gbak switches more than once in the same datbase.
3) The restore updates the indexes statistics, and the optimizer can choose new PLANs for the same (old)queries. Sometimes it can choose a worse plan, causing bad performance and high cpu/io load. You need to monitor your queries and see if some of them needs optimization.
4) If you are using SuperServer, you can try Classic or SuperClassic, since SS on Windows only uses 1 core per database. Take care with firebird cache memory consumption when using CS/SC.
HTH,
[]s
Carlos
Firebird Performance in Detail - http://videos.firebirddevelopersday.com
www.firebirdnews.org - www.FireBase.com.br
Hi We have DB of about 40GB where transaction counter exceeded max and we had to backup and restore to get the db back up an running. However after doing this we have had trouble where the DB consumes 25% CPU (100% on one core). This typically happens when accessing the DB from IIS web pages with quite a bit of transactions. However normally this work very fine without this 100% CPU core load. I find it hard to detect the real cause of the problem and also surprised that this should happen after a restore. One thing to mention that after the restore I had to recreate store procedures and trigger. From documentation on web I got the impression that this was caused by a encoding issue of text. Another thing to mention is that we are running the DB on Win 2008 Server and the fb version is 2.5.1. We also have the .GDB extension on the database, but since this has not been a trouble before, I doubt that this is the problem. What I have done so far is to: * validate the db * run manual sweep on it * restarted fbserver * restarted server * restarted IIS Right now I am starting each of the websites/services that are accessing the DB. Any suggestions on how to proceed? I am also interested in understanding better how I can better debug these situations. Right now I feel like I am just guessing about the cause and applying different potential fixes at "random". -- Jardar Maatje Nortek Data Services AS C.J. Hambros Plass 2C 0164 Oslo tlf: +47 95184034 |