Bugs item #988136, was opened at 2004-07-09 14:07
Message generated for change (Comment added) made by seanleyne
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109028&aid=988136&group_id=9028
Category: Linux ports
>Group: As Designed/Pitfall
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Camilo Olarte (colarte)
Assigned to: Nobody/Anonymous (nobody)
Summary: fbserver using 100% CPU in a 600MB database!
Initial Comment:
Hello, I have a problem when using a big database (>600
MB)...
I am using firebird 1.5 releases 8 and 9 in an athlon
1.8 Mhz with 512 Mb Ram ,running linux Red Hat 9,
with aproximately 64 tables and 109 stored_procedures
the fbserver process will use 100% of CPU when the
database file is over 600 Mb .
Here is how:
1. When using isql :
If i make a
Select count(1) from tbTable1 (where tbTable1 has
aproximately 300,000 records and 12 fields)
, when isql is closed fbserver returns to a normal
CPU usage .
2 . When using a connection embedded in apache
mod_python code.: the fbserver will consume 100% until
apache is restarted (connection from kinterbasdb restored)
Notes:
1. In a shorter database when i have a database
of 20Mb , this problems don't show.
2. In pc with less cpu and less memory ex( 256 Mb ,
celeron 900) , the process taking 100% will stay in
100% forever , until fbserver is restarted...
3. In Athlon Pc with 512 Mb Ram and 1.8 Mhz , and a
database of more than 600 MB, only large selects would
make fbserver consume 100% of CPU.
4 In Celeron Pc with 256 MB RAM and 900 Mhz . and a
database of more than 600MB, almost any select will
make fbserver use 100% CPU.
5. The fbserver will not crash , it would take the
all cpu for his use forever.
Had Done:
1. I have tried not to make select with un-indexed
fields in the WHERE clause... but even making selects
only on indexed fields will show this behavior.
thanks for any help,
Camilo Olarte
----------------------------------------------------------------------
>Comment By: Sean Leyne (seanleyne)
Date: 2004-07-13 22:45
Message:
Logged In: YES
user_id=71163
First, this is "as designed" functionality. Due to
Firebird's "multi-generational" design a SELECT COUNT()
statement must read each row to determine whether the row
is visible for the current transaction.
First, this is a support problem, not a bug report. Please post
any questions to the support list.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109028&aid=988136&group_id=9028
|
