> Tip 2: Your server is SMP, use Classic server.

Sorry, I totally disagree!!! I have followed similar advise from this
forum, and after going in circles for weeks went back to FB 2.1 64
bits Super server, installing 8 instances (1 for each processor), and
there is nothing better than that, at least for us. We have several
databases in use, and each processor is taking care of at least 1 DB.
We also have about 300 concurrent users.

Fabian

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>
> --- In firebird-support@yahoogroups.com, Victor Perez
> <victorjdc87@> wrote:
> >
> > Hello:
> >  
> > I am running firebird 2.0 in a Windows 2003 R2 operating system
> server machine with two Intel Xeon 3.20 Ghz processors and 4 GB of
> RAM. I have two hard disks HD1: one partition C: 135 GB in a RAID 5
>  and HD2: one partition E: 68 MB in stand alone configuration.
> >  
> > The database is running under SUPERSERVER configuration. I have
two
> databases in the system. SISTEMA.GDB (964 MB in size) installed in
the
> C: partition of HD1 (the same as the Operating system) and
> SISTEMA2.GDB (1032 MB)  installed in the HD2  E: partition
> >  
> > My problem is that when the database is under high demand from
> processes (i..e. payroll processing,  end of the month
sales/inventory
> reports, etc) and more number of users accessing (upto 30) the
> database, the system becomes very slow  and almost comes to a halt.
> >  
> > I have:
> >  
> > 1. Installed a seconday disk (HD2) dedicate to SISTEMA2 database
> only and configure our applications so that the use this database
the
> most. The idea was to have the main load in a HD which was not also
> using the Operating system
> >  
> > 2. tried to play around with the firebird.conf file and changed
the
> following settings to:
> >  
> > SortMemUpperLimit = 1582688000
> > DefaultDbCachePages = 409600
> > SortMemBlockSize = 134217728
> >  
> > Can anyone tell me what can I do to get the database running at
> optimum performance. I guess it will be worth noting that we have
> configure our application using a lot of begin and commit trans
which
> locks tables, we have done this to assure completeness of the
> transactions.
> >  
> > I will appreciate help.
>
> Tip 1: Don't hijack threads.
>
> When you reply to a message, your question will be given a reference
> number that attaches it to the message you reply to. Anyone using a
> newsreader (and most of the people with enough knowledge to actually
> answer your question will be!) will see your reply under someone
> else's question. They may have selected to ignore that thread and
will
> therefore *never* see your question.
>
> Tip 2: Your server is SMP, use Classic server.
>
> Superserver does not (in any released version) have the capability
to
> use more than one CPU core. You are wasting 3 of the 4 cores by
using
> Superserver.
>
> Tip 3: Fix your conf file for Classic server.
>
> Values that make sense for Superserver are not good for classic
> server. I would start with the default values for classic server,
then
> increase them after profiling. In particular, you must avoid at all
> costs creating caches so large that the OS must page the cache back
to
> disk. That is the worst of both worlds.
>
> Tip 4: Partitioning your drive does not reduce load on the disk,
> although a secondary hard drive will. That said, not all hard drives
> are equal. For example, moving your databases from a RAID volume to
a
> single drive may make it worse.
>
> Tip 5: On Windows, never give any files a .gdb extension. Use pretty
> much anything else - .fdb is a common one.
>
> Adam
>