---------- Original Message -----------
From: "justsome.rm" <frank@...>

> i installed that service yesterday but now still the same problem, the
> fbserver is using again 1,3 Gb of memory, any other ideas ?

------- End of Original Message -------

Continuing relevant thread, I'm seeing similar behavior:

Windows Server 2008 SP2 (which has a fix for the disk-cache problem Carlos
pointed out) with FB 2.1.4 Classic, with default settings (75 page cache * 16kb
page size, 8mb sort temp space). I'm using Tomcat + DBCP. I noticed today that
I had at least half of my FB processes sitting idle with 100mb to 200mb of RAM
allocated, and the other half (having done no work?) sitting at 20mb or so.
This was maxing out the server's physical RAM. The server's been (and is)
quiet, no load, so that's from casual usage.

No UDFs are being called that could have their own memory leaks. Blob temp-
storage could be an issue, but that's supposed to be garbage-collected at the
end of transactions, and all the connections where quiet. It's Win2kSP2, so
it's likely not the disk cache. It's FB 2.1.4, so it's not just 2.5.x.

Anyone else experienced this? Is there a way to tell what FB is using all that
RAM for? I don't have mon$memory_usage in 2.1, but it didn't look like that was
helpful earlier in the thread. The other settings suggest FB should have a
total footprint of maybe 15mb per connection, not hundreds. The one thing in
common is that I too have a lot of metadata, but I've not seen any formulas for
calculating how much RAM should be consumed per Classic process:

1400 relations
9500 fields
4500 indices
65500 dependencies (yes, lots of dependencies between triggers and procedures)
7300 triggers
2200 procedures
1300 generators

And if this is a known problem (or can be guessed at), is SuperClassic a viable
solution? (I'm still waiting for 2.5.1 to be released with fixes from 2.1.4, so
I'm not ready to move up yet, but I'd like to know -- for myself and the OP.)

-Philip