Subject Re: [firebird-support] Re: FBserver.exe takes 2 or even 4 Gb of memory
Author unordained
> Contradictory? Question, which OS and, if actually Server 2008, is it
> 32-bit or 64-bit?

Typo! Was meant to be Win2k8SP2, that's what I get for shortening it. The OS is
64-bit, the FB install is 32-bit. (I do have some UDF's, though not currently
in use, and I was tired of trying to get the 64-bit cross-compiling to work
with mingw. Easier to just use the 32-bit FB on dev, test, and prod machines
alike.)

>
> Also contradictory is the Subj, viz., "FBserver.exe takes 2 or even 4
> Gb of memory". If you are running FbServer.exe then you are running
> Superserver, not Classic.

True, but I think the original thread eventually went into Classic-land as
well, subject line never updated. This is for Classic.

>
> The other quick question is whether you are (inadvisedly) using the
> Guardian with Classic. (Guardian OK with fbserver.exe, not OK with
> fb_inet_server.exe, which is Classic.)

No guardian. I do still have abort_bugcheck = 1 though, from previous "freeze"
issues we had. (Haven't seen that happen in a while, which is nice. Thanks.)

I did some more experimenting last night: the FB processes start up at around
17mb and go up to 22mb or so regularly; they don't jump to 210mb until I make
use of the "workflow" trigger/procedure stuff, which is called from an on-
commit trigger, but via a conditional execute-procedure to prevent it from
being a hard-dependency (Helen, you might remember that mess from previous
questions I had.) At that point, RAM usage goes way up, and stays stable after
that. Basically my fb_inet_server instances are split between those that have
ever been asked to touch workflow, and those that haven't.

So I'm thinking the metadata cache is involved, so my questions about a formula
for calculating how much RAM it should use / whether SuperClassic will fix that
(shared cache) still seem appropriate. I can provide a metadata-only backup to
any developers interested in playing with the scenario. (The EMS guys had fun
with one when I had problems with their database-metadata-comparison tools
croaking on my dependencies. Their product gives it a good try, but ... I'll
admit, I may have overdone the metadata this time.)

Thanks Helen!

-Philip