At 04:00 PM 14/07/2005 +1000, you wrote:

>Hi everyone,
>
>I need help here.
>
>I've been battling with my system administrator on Firebird CPU load,
>apparently, it is exceedingly high. I am using CS on Red Hat Linux on a
>cluster. The script that uses Firebird is in Python, using KinterbasDB.
>I've ran my script for a few minutes and using "top", this is my
>comparison of load...
>
>29381 mling 15 0 48648 44m 2980 S 1.7 1.1 0:32.24 python
>29383 firebird 20 0 289m 74m 10m R 83.6 1.8 3:46.62 fb_inet_server
>
>The script only runs using 1.7% CPU but fb_inet_server uses 83.6% CPU. I
>can understand if FB's CPU usage is in spikes during DB access but it is
>not, 0:32.24 python versus 3:46.62 fb_inet_server.
>
>Any idea what may be happening?
>
>Page size is 4KB and buffer is set to 65365 (I cannot go any higher).
>
>If I run multiple scripts, I can use 3x99.9% CPU for the whole day and
>I'm having hell from my system administrator.

I don't blame him for getting upset about your resource usage! The way you
have the cache configured, EVERY CONNECTION is getting statically
allocated > 255Mb of RAM for its cache. A single connection really has no
way to use all that cache. Heck, it would even be outrageous to allocate
*that much* cache to a superserver, which allocates cache dynamically and
shares the cache amongst all of its connections. Revert it to the default
75 pages, i.e. 300Kb per connection, which should be ample. Just be sure
that you have enough RAM on the system to support the number of concurrent
connections you expect.

What is yomping up CPU? Disk i/o gone wild as your seriously RAM-starved
system juggles what's left back and forth to/from swap? Operations queued
up waiting for resources? Multiple processes all running similar
CPU-intensive ops on the server? ????? First thing to eliminate will be
that RAM greed...

./heLen