At 08:43 a.m. 20/02/2013, Thomas Steinmaurer wrote:

>>
>> As you say, the sum of those 9 page caches will be significant in the consumption of available RAM. Additionally, each connection to the SS process spawns a thread that eats the same amount of RAM as the main process

At 08:43 a.m. 20/02/2013, Thomas Steinmaurer wrote:

>Are we talking about the page cache here only? I'm curious, because this
>would mean we are close to the CS/SC architecture then. ;-)

No, not closer than it ever was. SS has one shared cache per open database. CS/SC have one cache per connection. The OP has 9 databases per customer. He has n customers (we don't know how many, do we?) So, in 2GB of RAM, SS will be maintaining 9 * n caches of unspecified sizes as well as (potentially) 9 * n * m SS threads (each circa 3.5 MB), where m is the total number of client connections.

>> although there's not necessarily a 1:1 correspondence as the server will reallocate a recently de-allocated thread if one is available. My point was that RAM usage will accumulate towards a tipping point on an under-resourced system like this one.
>
>I fully agree, although I doubt that getting CPU bound is the result of
>running out of RAM.

50% is CPU-bound? The main symptom of the OP seemed to be the inability of the server to accept new connections.

Actually, it would be interesting to know whether this 32-bit box has SMP. The OP also implied that Oracle and a webserver were hosted on the same box...


Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.ibphoenix.com/products/books/firebird_book
__________________________________________________________________