I will try to change to Classic Server

--- In firebird-support@yahoogroups.com, "Nigel Weeks" <nweeks@...>
wrote:

>
>
> > I have a Red Hat v9 2.4kernel with Fb 1.5 Superserver. I´am

using ext

> > 3 for the Partition Type.
> > 100 users use thist Server to access a single Database.
> > The Server Hardware is an IBM Server Series 206, with 3GB Ram

and 2

> > disks in Raid 1.
>
> > Is this OS the best choice for my equipment ?
>
> Unix is always a better choice if you've got support people for

it, and

> management/your boss lets you use it.
> Windows has poor SMP support, and requires process affinity if you

have

> multiple CPU's to overcome scheduler inadequacies(process

shuffling between

> unloaded CPU's) when dealing with small numbers of highly CPU

hungry

> processes(SuperServer).
>
> > Does Fb runs better with a Server 2003 and NTFS ?
> It will run slower than a decent unix
>
> > Does Fb Clasic Server run s better for 100 users with 3Gb of

Ram ?

>
> It depends on what your application does, and how it's used.
>
> SuperServer has a large central cache where record sets are stored

for quick

> access by the same query run at a later stage. It lends itself

strongly to

> applications where the same information is requested very

frequently, as

> cache hits are faster than going down to disk, and pulling records.
> SS, therefore, it great for OLTP (On-Line Transaction Processing) -

short,

> simple transactions and queries.
> On the other hand, SuperServer is a single-process, multi-threaded

model

> server(and can thusly only use one CPU), and while all

architectures of

> Firebird have exclusive "serialized" sections where only one

operation can

> occur at a time(new page request, etc), SuperServer has the

tendency to

> stall other transactions/operations if a large, complex query is

performed.

> Rest assured, the other operations will be performed, but their

requests

> will be serialized, and done one after the other. Therefore, if

it's deep

> reporting you're after, SuperServer might not be the ideal choice.
>
> Classic Server has a cache inside every process that's launched to

do

> database operations (one process per connection). If these

connections are

> re-used(persistent connections), the caches can result in very

high speed

> operation - at the expense of ram. On most OS's, each process has

it's own

> executable space in memory, then it's data space, which swells to

contain

> it's cache space, and can get large if persistent connections

aren't closed

> regularly.
> On the other hand, Classic will scale enormously. It will use as

many CPU's

> as you can throw at it, and allow massive amounts of operations to

be

> performed simultaneously. Some sections of some operations are

still

> serialised, as Firebird needs to keep track of new/deleted pages,

etc, but

> it hammers along.
> Deep, complex reports can be performed with little impact on other

users,

> especially if you're using SMP hardware. Very stong for OLAP (On-

Line

> Analysis/Analytics Processing).
>
> So, in a nutshell, there is no one "Ideal Solution". There are

two "Ideal

> Solutions" - perfectly tuned and tailored to your needs.
> Super Server:
> Ram Usage: Low, with large central cache
> Simple Query Speed: Amazing if it can pull from the cache
> Doesn't like: Long, complex queries(Causes a pause on other

operations

> until complete)
> SMP suitablilty: Poor. If allowed to swap between CPU's on a

windows box,

> it'll run like a dog, and can only use one CPU at the best of times
> Ideal Uses: Web Content Management, POS systems, data

aquisition, logging,

> network traffic logging/recording
>
> Classic Server:
> Ram Usage: Medium to High, especially if persistent connections

aren't

> recycled
> Simple Query Speed: Amazing if persistent connections are used,

great

> otherwise
> Doesn't like: Not so thrifty with ram, and having multiple

caches can

> result in cache misses, meaning records will be pulled from disk

if the

> result is not in this process's cache
> SMP Suitability: Brilliant. Scales almost linearly across CPU's
> Ideal Uses: accounting systems, CRM, ERP, logistics/transport

systems,

> deep reporting systems.
>
> Two ideal solutions, depending on your needs.
>
>
> > Another Question.
> > How can I check if The Raid Card is apropiate for my workload ?
> > Can I see some statictis or something else ? I have not

experience

> > with Linux.
>
> On FreeBSD, I can do a `systat -iostat 1`, and see the load on disk
> subsystems. There should be a similar tool on Linux.
>
> N.
>