Sean,

Thank You for the fast response, Your suggestions are greatly appreciated.

> We have FB 2.5.2 SS running on Win2003/x32 and Win2008/x64 servers.
> > around 50 - 150 user connects to de databases .
>
> I would recommend that you move to Classic engine, your system will
> perform better with that number of users.
>

> > Every now and then some of our clients' FB server service freezes at the
> time
> > we issue an ALTER DATABASE BEGIN BACKUP or start an nbackup session.
> > After the freeze the FB service stops responding, and only hard stopping
> the
> > process helps.
>
> The "freeze" is the result of 2 items.
>
> 1 - The SuperServer engine is a single thread which provides
> pseudo-multi-threading for connections.
>
> 2 - NBackup is a very disk IO intensive.
>
> It is very easy for NBackup to consume all available engine and server
> disk resource while is it running (changes have been made to try and make
> it "friendlier" to simultaneous operations, but there is only so much which
> can be done)
>
> Given your database size and the number of remote connections, I would
> strongly recommend changing to Classic engine. It will allow for more
> consistent responses for the remote connections.
>

Your suggestion to change to Classic engine is one thing I really consider.
It needs to be planned carefully in our case because the system is operated
without real competent supervision and our operating mechanisms - that were
serving us well in the past 10 years, starting from IB 6.0 - relying on
some specialties of the SS architecture, like stopping the FB service.

One thing is not clear to me however. ALTER DATABASE shouldn't be IO
intensive, also the server computers seem to handle the traffic of nbackup
really well. We have monitored the resources at the moment when the FB
service stopped responding, but no memory, Disk/Network IO or CPU overload
happened.

I might not be clear about the "freezing" behavior. The FB service seem to
be running but no response at all, the existing connections are not served
and no new connections could be made until killing the process and
restarting the FB service. This kind of behavior is not expected at all,
the process should get into some usable state after the bottleneck is
eliminated.

>
>
> > I couldn't identify any problem at the database or environment level.
> Some
> > 10057 and 10061 error can be found in the firebird log before the
> freeze, but
> > these messages are quite common even the system and the nbackup
> > sessions otherwise working well.
>
> The errors are unrelated to the "freeze"
>

That's what I figured out too.

>
>
> > The database sizes are around 10 - 30 GB
> > and are fully backuped and restored at every weekend.
>
> Why are you performing regular backup/restore?
>

As I mentioned these systems operated without much supervision and
monitoring and a lot of different problem can be solved (although they may
happen infrequently or even never) by issuing a full backup/restore. It may
sound a bit tough but it saves us s lot of headache.

Thanks again for Your detailed suggestions.

Regards

Zsolt

>
>
> Sean
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>
>
>

[Non-text portions of this message have been removed]