As FB 1.5 doesn't has the TraceAPI and MON$ tables, I guess your best
option is to use IBSurgeon's FBScanner to monitor the talk between
clients and server and find out who is the guilty.

[]s
Carlos
Firebird Performance in Detail - http://videos.firebirddevelopersday.com
www.firebirdnews.org - www.FireBase.com.br

v> We are consolidating some Firebird 1.5 databases that have been
v> running for many years without issue, and have moved them to a
v> CentOS 5 64 bit server, away from their original CentOS 32 bit
v> server. Everything appeared to be fine following migration - these
v> are web applications so we tested them and they were operating ok.

v> About a day or so later, the Firebird 1.5 Super Server on the new
v> CentOS server went into some form of tailspin. TOP reported it at
v> 99% CPU and running over and over. Client applications stalled.

v> In attempting to diagnose where the problem was coming from, we
v> restarted the clients but that made no difference. We could not
v> regain control of the Firebird process and the only fix was a
v> complete server reboot on the Firebird server. Following that, everything returned to normal.

v> This has been repeating now every 1-2 days with no sign of why.
v> I've checked Firebird.log and there is nothing there to identify
v> any issues. There are 5 databases (.fdb) on that server, and all
v> are active. Any one of them could be cause of this, but I'm
v> completely in the dark as to the root cause. I've checked with
v> gstat and nothing appears out of the ordinary. These files were
v> backed up to FBK files on the original server, scp'd to the new box and restored there.

v> I've run gfix over them with -v -f flags, sweep and mend options. Nothing appears to be an issue.

v> What is the best way to determine which database or query is
v> consuming all the resource on this server? Is there anything in FB
v> 1.5 that logs incoming connection requests so that we can at least
v> identify what connections were active at the time of the server
v> lockup? That might allow us to isolate this down to at least a
v> single database, or if evidence shows that it doesn't seem to be
v> specific to a database, we can diagnose the OS to see if there are any problems there.

v> Any suggestions, advice, etc. is greatly appreciated.

v> Thanks
v> Myles



v> ------------------------------------

v> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

v> Visit http://www.firebirdsql.org and click the Resources item
v> on the main (top) menu. Try Knowledgebase and FAQ links !

v> Also search the knowledgebases at http://www.ibphoenix.com

v> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
v> Yahoo! Groups Links