Subject | Re: [firebird-support] Re: FBserver.exe takes 2 or even 4 Gb of memory |
---|---|
Author | unordained |
Post date | 2011-07-06T20:17Z |
> Contradictory? Question, which OS and, if actually Server 2008, is itTypo! Was meant to be Win2k8SP2, that's what I get for shortening it. The OS is
> 32-bit or 64-bit?
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.)
>True, but I think the original thread eventually went into Classic-land as
> 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.
well, subject line never updated. This is for Classic.
>No guardian. I do still have abort_bugcheck = 1 though, from previous "freeze"
> 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.)
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