Firebird database tuning for multiprocessor

I'm running a software called Fishbowl inventory and it is running on a firebird database (Windows server 2003). At this time the fishbowl software is running extremely slow when more then one user accesses the software. I'm wondering if anyone could provide some information on tuning the database or best practices? We are currently running a dell power ed开发者_如何学运维ge 2700 dual quad core with 4 gig's of ram. Any help would be greatly appreciated.

Thank you in advance. Robert

I do report development for Fishbowl Inventory (2009.1-2010.2) and my business partner is a Fishbowl VAR. We have dealt with customers with slow databases. oGive me a shout at ilopez at fishbowlreports dot com

It is odd that your server with those specs is showing lag, but It is not unheard of.

Top Three Things To Keep In mind

1) Database Size - The larger the db, the more rows it has to deal with when working on reports/updates, etc. 2) Activities - Certain activities pound on the server 3) Version - The newer fishbowl versions have additional indexes on the tables, which allow faster queries

In my experience most of the tasks increase in time linearly by the work done. see: http://www.fishbowlinventory.com/forums/viewtopic.php?f=16&p=5240 - I did some benchmarking on Fishbowl Inventory 2009.3, hope to do the same in Fishbowl 2010.2 (Once it is released).

-Israel

For good tuning information on Firebird database: look at the documentation you can find on www.ibphoenix.com.

I think the problem is not from the Firebird Database. IbPhoenix can help you but you also have to ask your Fishbowl ressealler.

• First thing : choosing between Firebird SuperServer or Firebird ClassicServer
• Increase cache for database

other interresting links :

• http://www.ibphoenix.com
• http://www.ibsurgeon.com/knowledgebase/
• http://www.sinatica.com/

Take a look in Firebird Performance in Detail video from Dmitry Yemanov (chief of Firebird development team). Also, if you are using SuperServer, make sure that FB is attached to a single CPU/core (check CPUAffinity parameter in firebird.conf).

Usually. A bad transaction handling from client part, produce a lot o record versioning. Extract using gstat statitistical data and look for "total version" for each table. Ideal value is 0 for every table. When total version is greather than total efectives records, we are in trouble.