Subject | Re: Debug and stress test |
---|---|
Author | robertvilhelmsen |
Post date | 2007-07-01T15:02:19Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:
the same problem as this thread:
http://tracker.firebirdsql.org/browse/CORE-1297
This specific server has been running for month fine. Several month
with one 10Gb DB, 2 month with one 10Gb DB and one 300Mb DB.
After adding a 3. database (size 200Mb) suddenly the largest DB stops
with:
operation was cancelled
internal gds software consistency check (error during savepoint
backout (290))
It happens when the fbserver service runs with approx. 40% cpu usage
and above with approx. 100 concurrent connections. But again - it´s
very infrequent.
The actual database has no corruption and is running just fine after a
restart of fbserver service.
To me it looks like a fbserver issue when there´s:
1. a lot of ongoing transactions
2. fairly many concurrent connections
3. more than one database attached to the server
Changing server, cpu afinity, hypertreadning ect. do not fix anything.
/Robert
wrote:
>I have read through Firebird tracker open issues and think I might have
> At 08:12 AM 1/07/2007, you wrote:
>
> You should be able to find the debug builds from obsolete releases at
> the production download area at sourceforge:
> http://prdownloads.sourceforge.net/firebird
>
> Look for the file infix "pdb".
>
the same problem as this thread:
http://tracker.firebirdsql.org/browse/CORE-1297
This specific server has been running for month fine. Several month
with one 10Gb DB, 2 month with one 10Gb DB and one 300Mb DB.
After adding a 3. database (size 200Mb) suddenly the largest DB stops
with:
operation was cancelled
internal gds software consistency check (error during savepoint
backout (290))
It happens when the fbserver service runs with approx. 40% cpu usage
and above with approx. 100 concurrent connections. But again - it´s
very infrequent.
The actual database has no corruption and is running just fine after a
restart of fbserver service.
To me it looks like a fbserver issue when there´s:
1. a lot of ongoing transactions
2. fairly many concurrent connections
3. more than one database attached to the server
Changing server, cpu afinity, hypertreadning ect. do not fix anything.
/Robert