Subject | Re: [firebird-support] Linux server optimization for FB 1.5 SS? Best practice guide? |
---|---|
Author | Steve Wiser |
Post date | 2011-08-22T17:52:50Z |
Definitely switch to classic and make sure to update the CPS setting for
xinetd and the max number of instances allowed (/etc/xinetd.conf) if you
will have a lot of connections being made. I think we also up the semaphore
setting as well (both in /etc/sysctl.conf and firebird.conf).
I also like to move the OS stuff to a separate drive container (usually
running RAID 1) with the DB partition running on a RAID 5 setup like you
described.
-steve
--
Steve Wiser
President
Specialized Business Software
6325 Cochran Road, Unit 1
Solon, OH 44139
www.specializedbusinesssoftware.com
www.docunym.com
(440) 542-9145 - fax (440) 542-9143
Toll Free: (866) 328-4936
xinetd and the max number of instances allowed (/etc/xinetd.conf) if you
will have a lot of connections being made. I think we also up the semaphore
setting as well (both in /etc/sysctl.conf and firebird.conf).
I also like to move the OS stuff to a separate drive container (usually
running RAID 1) with the DB partition running on a RAID 5 setup like you
described.
-steve
--
Steve Wiser
President
Specialized Business Software
6325 Cochran Road, Unit 1
Solon, OH 44139
www.specializedbusinesssoftware.com
www.docunym.com
(440) 542-9145 - fax (440) 542-9143
Toll Free: (866) 328-4936
On Mon, Aug 22, 2011 at 1:43 PM, Alexey Kovyazin <ak@...> wrote:
> **
>
>
> Hello Myles,
>
> Switch to 1.5.6 Classic, set in firebird.conf
> DefaultDbCachePages = 512 and you'll see the difference which should be
> enough.
>
> Regarding migration - look at Profitmed migration case study
>
> http://www.slideshare.net/ibsurgeon/firebird-migration-from-firebird-15-to-firebird-25
>
> Regards,
> Alexey Kovyazin
> IBsurgeon
>
>
> > I have a new FB 1.5.6 Linux Super Server installation going online.
> > This will eventually be upgraded to 2.1 or 2.5 but we have legacy code
> > that keeps us in 1.5.6 for now.
> >
> > I have installed a 'default' build of FB 1.5.6 on CentOS 64 bit server,
> > and its running as a virtual machine on OpenVZ/Proxmox. The
> > configuration of the server is like this:
> >
> > Dell PowerEdge 2950, Dual Xeon 2.6Ghz CPUs (2 core per CPU I believe)
> > RAID 5, with 3 x 1TB drives, 1 x 1TB Parity, and 1 Hot spare
> > 16GB of RAM total for server, with 6GB allocated to CentOS for FB Server
> > 1GB NICs
> >
> > The database feeds a web application running on a separate box.
> >
> > I have not applied any changes to the default firebird.conf setting.
> >
> > The server, under light load (about 8 users), is reporting a higher than
> > normal CPU load, but almost no RAM load.
> >
> > The most intensive queries involve a lot of row retrieval, sorting and
> > display, and I do not believe I have optimized this for sorting at all.
> > Nor have I optimized for CPU affinity (which I'm not even sure I can
> > do with SS 1.5.6 on Linux). I have also not optimized Cache size, and
> > the DB is reporting page size at 16384.
> >
> > So can anyone give me a suggestion as to where to start to get more
> > performance out of this beast? I know that FB upgrade would help a lot,
> > but I can't address that in the next few months at least so I have to
> > work with what I have got right now. I'm seeing that simple queries
> > appear to be pretty fast, but the more complex ones that are already
> > highly optimized are loading the server.
> >
> > Any thoughts?
> >
> > Myles
> > --
> > -----------------------------
> > Myles Wakeham
> > Director of Engineering
> > Tech Solutions USA LLC
> > www.techsolusa.com
> > Phone +1-480-451-7440
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
> This message and any files transmitted with it may contain information that
> is privileged, confidential, and exempt from disclosure under applicable
> law. They are intended solely for the use of the intended recipient. If
> you are not the intended recipient, distributing, copying, disclosing, or
> reliance on the contents of this communication is strictly prohibited. If
> this has reached you in error, kindly destroy this message and notify the
> sender immediately. Thank you for your assistance.
>
> We attempt to sweep harmful content (e.g. viruses) from e-mail and
> attachments, however we cannot guarantee their safety and can accept no
> liability for any resulting damage. The recipient is responsible to verify
> the safety of this message and any attachments before accepting them.
>
[Non-text portions of this message have been removed]