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 __________________________________________________________________
