| Subject | Re: [firebird-support] Re: FB 1.5 Crash |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-03-03T23:11:06Z |
At 10:28 PM 3/03/2004 +0000, you wrote:
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.
Next, each attachment uses some space. For SS, it's about 150 Kb, afair.
When the first user logs in, the server creates a state bitmap of
"interesting transactions". It maintains this bitmap (in memory, of
course) as long as there are any connections, as transactions change
state. It removes state info for transactions that are cleanly committed
and adds state info for new transactions. "Cleanly committed" =
transactions that pass from active to committed. Transactions that are
committed with CommitRetaining don't change state. Transactions that are
rolled back change state to "rolled back" and will get dealt with by the
next sweep. If you have sweep interval set to 0, they won't ever get their
state changed to committed and will just stay "interesting".
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).
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...
The server also uses memory to maintain its lock table. Needless to say,
the more transactions running, the bigger the lock table grows.
In 1.5, the server will try to get memory resources for storing the
intermediate sets for sorts and sort-merges if it can.
So, you see, the cache and the memory it takes to load the server program
is but a part of what the server needs.
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.
Mb. There's a vast difference between that and 128 Mb, no matter how
skeptical you are.
/heLen
>Hi Hellen,When no users are connected, the cache is unallocated. It gets allocated
>
> > >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 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.
Next, each attachment uses some space. For SS, it's about 150 Kb, afair.
When the first user logs in, the server creates a state bitmap of
"interesting transactions". It maintains this bitmap (in memory, of
course) as long as there are any connections, as transactions change
state. It removes state info for transactions that are cleanly committed
and adds state info for new transactions. "Cleanly committed" =
transactions that pass from active to committed. Transactions that are
committed with CommitRetaining don't change state. Transactions that are
rolled back change state to "rolled back" and will get dealt with by the
next sweep. If you have sweep interval set to 0, they won't ever get their
state changed to committed and will just stay "interesting".
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).
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...
The server also uses memory to maintain its lock table. Needless to say,
the more transactions running, the bigger the lock table grows.
In 1.5, the server will try to get memory resources for storing the
intermediate sets for sorts and sort-merges if it can.
So, you see, the cache and the memory it takes to load the server program
is but a part of what the server needs.
>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.
>But I also believe that if there is any possibility, it has toThe default is always a good place to start. The installation default is 8
>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?
Mb. There's a vast difference between that and 128 Mb, no matter how
skeptical you are.
/heLen