>>> There's another resource aspect in this case, too: SS is a single process running on a 32-bit server so it's limited to 2GB total memory. So, with "9 separate database files for each of the connecting agencies" and an unknown number of connections to each database by each agency, there will be a tipping point where there's not enough RAM to make a new connection.
>
> At 07:58 a.m. 20/02/2013, Thomas Steinmaurer wrote:
>
>> Could be, but as he is using SuperServer, the number of connections
>> isn't in the equation, so it's the sum of page caches per database.
>
> 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

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. ;-)

> 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.

--
With regards,
Thomas Steinmaurer
http://www.upscene.com/