Subject Re: Best OS tu use with Firebird ??
Author diegodelafuente
I will try to change to Classic Server

--- In, "Nigel Weeks" <nweeks@...>
> > 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
> multiple CPU's to overcome scheduler inadequacies(process
shuffling between
> unloaded CPU's) when dealing with small numbers of highly CPU
> 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) -
> simple transactions and queries.
> On the other hand, SuperServer is a single-process, multi-threaded
> 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
> Rest assured, the other operations will be performed, but their
> 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
> 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
> 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
> performed simultaneously. Some sections of some operations are
> 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
> especially if you're using SMP hardware. Very stong for OLAP (On-
> 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
> 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
> recycled
> Simple Query Speed: Amazing if persistent connections are used,
> 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
> 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
> > 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.