Maurice,

>> According to my experience, what makes firebird eat cospicuous
>> amounts of CPU cycles is usually:
>> - scanning indexes with lots of duplicates.
>> - scanning records with many backversions (i.e. garbage).
>> - sorting (much less than the other two items).
>>
>> So, I guess the solution for your issue has to pass through analysis
>> of the SQL query or queries you are executing, their PLAN, the
>> database structure (indexes, etc.) and possibly database statistics
>> (run gstat -h on the database and report back here).

ML> No idea what you are trying to ask but here is the gstat -h on the
ML> database...

the stats look more or less OK (I assume you don't need forced writes
in your configuration).

I'll try to explain myself better.
If your fb processes are consuming CPU, either they are doing it
because they need it to perform the jobs you are throwing at them,
or they are suffering from one of the problems outlined above:

- scanning indexes with lots of duplicates.
- scanning records with many backversions (i.e. garbage).
- sorting (much less than the other two items).

In the former case, I guess you're pretty much stuffed; in the latter,
my goal would be to find whether there are things in the database
structure and/or the queries that could cause those problems or not.

To do that you should post database structure, queries and query
plans.

I have always thought that a database server should be disk-bound
rather than cpu-bound, yet some of the posts I see in this thread seem
to contradict this.

Ciao
--
Nando Dessena
http://www.flamerobin.org