| Subject | RE: [firebird-support] Re: Fbserver eating CPU...not taking advantage of memory |
|---|---|
| Author | Aaron Abend |
| Post date | 2005-05-21T00:53:52Z |
Sorry I had no idea that starting an email by replying to an existing item
would hijack the thread. Thanks for pointing it out I will not do that
in the future.
As for the machine, the machines that work well have hyperthreaded cpus
(though we have tested in many single cpu environments without the serious
problem we see on this one machine). The machine with the problem is a
particularly slow cpu (1.2 GH something-er-other probably not a pentium).
Are you using a different versions of Firebird?
No all of these machines are running fresh installs of our product,
which installs Firebird Superserver as a local system service (i.e. not
embedded and not running the fbserver interactively).
Does this machine have two CPUs whereas the others have one CPU?
No, one CPU not fast.
Different data making the optimiser choose a different plan for the
same query?
Same application, could be looking at more data but we do not think
so.
Different type/number of users?
Single user
Less available harddisk space for temporary files?
Will look into this
Inactive indexes?
I would say no because all machines use the same app. But the app
drops and recreates indexes and it is remotely possible that the indexes did
not get rebuilt. I will check that. Unfortunately I am away from the machine
with the problem until Monday. I will check it then.
My question was intended to see if there were some known issues that would
prevent FB from using more memory, which might therefore put more pressure
on the CPU (I know this can happen with SQL Server and Oracle).
I have increased the DefaultDbCachePages to 5120 pages and we use 16k pages
so it should be able to go up to 80M on this machine (which is running xp
with 512M ram). But all it uses is 20M. why wont it use more? Is some other
parameter limiting memory use? Or is memory simply not the problem and it
just needs a ton of CPU to process the queries?
We are going through the code to see exactly what the queries are. Any
performance ideas would be welcome. We are already rewriting a lot of
queries to minimize the number of correated subqueries and rewriting some
complex queries as procedures. Were trying to get every ounce of
performance.
Thanks,
Aaron
-----Original Message-----
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Svein Erling Tysvær
Sent: Friday, May 20, 2005 6:36 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: Fbserver eating CPU...not taking advantage
of memory
Hi Aaron! Why did you hijack "FB 1.5.2 terminates abnormally (-1)"
(second time in less than 24 hours I answer a hijacked thread in this
forum)? Never hit 'Reply' when your question is of no relevance to the
thread.
Something has to be different with this machine compared to the other
ones.
Are you using a different versions of Firebird?
Does this machine have two CPUs whereas the others have one CPU?
Different data making the optimiser choose a different plan for the
same query?
Different type/number of users?
Less available harddisk space for temporary files?
Inactive indexes?
I cannot help you unless you tell us how this machine differs (in
fact, I doubt I could even if you told us the cause), but others will
have more ideas.
HTH,
Set
would hijack the thread. Thanks for pointing it out I will not do that
in the future.
As for the machine, the machines that work well have hyperthreaded cpus
(though we have tested in many single cpu environments without the serious
problem we see on this one machine). The machine with the problem is a
particularly slow cpu (1.2 GH something-er-other probably not a pentium).
Are you using a different versions of Firebird?
No all of these machines are running fresh installs of our product,
which installs Firebird Superserver as a local system service (i.e. not
embedded and not running the fbserver interactively).
Does this machine have two CPUs whereas the others have one CPU?
No, one CPU not fast.
Different data making the optimiser choose a different plan for the
same query?
Same application, could be looking at more data but we do not think
so.
Different type/number of users?
Single user
Less available harddisk space for temporary files?
Will look into this
Inactive indexes?
I would say no because all machines use the same app. But the app
drops and recreates indexes and it is remotely possible that the indexes did
not get rebuilt. I will check that. Unfortunately I am away from the machine
with the problem until Monday. I will check it then.
My question was intended to see if there were some known issues that would
prevent FB from using more memory, which might therefore put more pressure
on the CPU (I know this can happen with SQL Server and Oracle).
I have increased the DefaultDbCachePages to 5120 pages and we use 16k pages
so it should be able to go up to 80M on this machine (which is running xp
with 512M ram). But all it uses is 20M. why wont it use more? Is some other
parameter limiting memory use? Or is memory simply not the problem and it
just needs a ton of CPU to process the queries?
We are going through the code to see exactly what the queries are. Any
performance ideas would be welcome. We are already rewriting a lot of
queries to minimize the number of correated subqueries and rewriting some
complex queries as procedures. Were trying to get every ounce of
performance.
Thanks,
Aaron
-----Original Message-----
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Svein Erling Tysvær
Sent: Friday, May 20, 2005 6:36 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: Fbserver eating CPU...not taking advantage
of memory
Hi Aaron! Why did you hijack "FB 1.5.2 terminates abnormally (-1)"
(second time in less than 24 hours I answer a hijacked thread in this
forum)? Never hit 'Reply' when your question is of no relevance to the
thread.
Something has to be different with this machine compared to the other
ones.
Are you using a different versions of Firebird?
Does this machine have two CPUs whereas the others have one CPU?
Different data making the optimiser choose a different plan for the
same query?
Different type/number of users?
Less available harddisk space for temporary files?
Inactive indexes?
I cannot help you unless you tell us how this machine differs (in
fact, I doubt I could even if you told us the cause), but others will
have more ideas.
HTH,
Set
--- In firebird-support@yahoogroups.com, "Aaron Abend" wrote:
> Hi all,
>
> I have installed fbserver (superserver) and when it starts serving
> database requests from my application, fbserver proceeds to eat 99%
> of the CPU and the user's system essentially hangs as the
> application itself is starved. I have allocated more memory to the
> server in firebird.conf but it does not seem to go past 20MB. I'd
> be happy to let it eat twice that much RAM if it would leave the
> CPU alone.
>
> Is there any way to configure/control Firebird's appetite for CPU?
>
> I have not seen this problem on machines (with faster CPUs), so
> there is a possibility there is a local problem that is causing a
> problem on this specific machine. But my guess is that it is
> something I will have to know as I roll my application out to other
> users. All ideas welcome.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit http://firebird.sourceforge.net and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !
Also search the knowledgebases at http://www.ibphoenix.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
_____
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/
* To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com
<mailto:firebird-support-unsubscribe@yahoogroups.com?subject=Unsubscribe>
* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]