Maurice,

ML> I've set the buffer back to 75, stopped and restart my script.
ML> A bath... a snack... and 30 minutes later, this is the "top" output...

ML> 30342 mling 15 0 48616 44m 2980 S 0.3 1.1 0:38.35 python
ML> 30343 firebird 20 0 15000 12m 10m S 65.3 0.3 2:08.87
ML> fb_inet_server

ML> FB takes about too long and too much CPU to run, compared with the
ML> calling script.

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> I do not know how to explain that the average load of my script is
ML> about 0.3-1.8% CPU while FB database access is 50-85% CPU load.

I don't think it's useful to compare the CPU load of a (thin) client
and a database server anyway.

ML> Alright, when I used buffer size of 75 and running 3 scripts, the 3
ML> fb_inet_server processes run at 3 x 99.6% CPU load while my scripts
ML> run at 3 x 1.5% CPU load. When I increase the buffer to 40000, the FB
ML> processes uses about 3 x 70% CPU load with no change to my scripts'
ML> CPU usage.

You should find a buffer size that suits your needs. My rough guess is
that 75 is not enough, just as 65535 was way too much. Estimate the
max number of concurrent connections you are going to need, the max
amount of RAM you would like firebird to ever allocate and calculate
your buffer size.

ML> To my system administrator, I am strongly advised to use a REAL
ML> DATABASE SERVER.

So, I should take note that a REAL DATABASE SERVER is one that doesn't
use the CPU. Just joking.
Ciao
--
Nando Dessena
http://www.flamerobin.org