Helen,

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

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

afair.

<skip nice exercise on MGA internals>

> In summary, the way a lot of people write applications, the TSB is

quite

> large and tends to get larger and larger. (consumes more and more

memory).

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

an

> under-spec'ed server if the TSB has been allowed to bloat and

bloat...

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

controlled

> shutdown. But if there is not even enough memory to do that, then

the

> 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

memory

> 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

hours

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

how

> skeptical you are.

Ok, I´ll go that way.

Thanks again,
dog