Subject Re: FB 1.5 Crash
Author precari0

--- In, Helen Borrie <helebor@t...>
> At 10:28 PM 3/03/2004 +0000, you wrote:
> >Hi Hellen,
> >
> > > >16KB DB page size, 8192 buffers.
> >
> > > You are using 128 Mb of your server's total 512 Mb for
> > > cache!! Intermittent crashes are therefore not urprising.
> >
> >I'm not sure what is the problem here.
> > >From a total of 512MB,
> >about 100MB is eaten by W2k,
> >some 160MB by Firebird (cache+server).
> >There is still 252MB free.
> >Please explain.
> When no users are connected, the cache is unallocated.
> It gets allocated when one user logs in.
> So just inspecting memory consumption when the
> server is at rest doesn't tell you anything about memory usage when
> it is serving requests.

The memory numbers I posted are actual readings.
In that given moment FBServer.exe was consuming
~160MB while serving 45 connections.
As mentioned in earlier posts, memory usage is being monitored
and the results of this monitoring will be posted here asap.

> Next, each attachment uses some space. For SS, it's about 150 Kb,

<skip nice exercise on MGA internals>

> In summary, the way a lot of people write applications, the TSB is
> large and tends to get larger and larger. (consumes more and more

Yes, very true.
If those same lot of people where running their buggy apps on FB1.0
they would run into trouble a lot earlier since FB 1.5 is much faster
and efficient at traversing record chains, right?
Well, that´s not my case.
Please, if you have any other doubt about this particular problem,
ask the question that may lead to the solution, don´t make
I´ll be more than glad to answer them.
I know I am the one in need of help, but if that help comes the way
you´re putting it, I might just look for it elsewhere.

Helen, I´m sorry if this sound harsh. It´s not meant to be.

> Next, each snapshot transaction (concurrency or consistency) gets
its own
> copy of the TSB. No big deal if the TSB is small. A challenge to
> under-spec'ed server if the TSB has been allowed to bloat and

I could go hours telling you what "under-spec´ed" means here in
Brasil for
small to mid-sized companies. :)
For the record: one of our customers runs the very same system on
a P3 900, 120Mb (onboard video uses the other 8),
20GB 5400rpm ide disk, FB 1.03, 1.5GB db size,
peak of 65 connections. Last time it was shut down for an upgrade it
had been running 4 months straight.
2Ghz+512MB is a damn good server, really.

> >Anyway, I believe the server shouldn't crash. In any case.
> Ideally, the OS should send the server a message when it is unable
to meet
> memory resource requests, and the server can then respond with a
> shutdown. But if there is not even enough memory to do that, then
> server can only crash. But configuring the server in a way that
the system
> cannot possibly satisfy is NOT the best way to approach the
> problem...especially on Windows. If Win2K was able to manage
> properly, you would never get the BSOD. But I get the BSOD on
Win2K with
> Word on a system with 1.5 Gb of RAM and oodles of "spare" memory.

C´mon Helen. Don´t do that.
I do have to answer support questions myself, you know, but going
the easiest way, blaming windows, just doesn´t cut it anymore.
You´re getting bsods? Check the quality of your hardware and drivers,
check for viruses, just don´t tell me it´s windows' fault, please.
No IT professional, no matter how much he/she hates windows, is
stupid enough
to believe it.

> >But I also believe that if there is any possibility, it has to
> >be tested. :)
> >I'll lower these values tomorrow morning (which means about 14
> >from now) and see what happens.
> >
> >What do you think of:
> >8KB PageSize * 2048 buffers = 16MB ?
> >Is it a good point?
> The default is always a good place to start. The installation
default is 8
> Mb. There's a vast difference between that and 128 Mb, no matter
> skeptical you are.

Ok, I´ll go that way.

Thanks again,