Page 2 - Firebird database too slow

Hi mheron, please keep us updated on this issue, I think it would be interesting for others to know more about performance issues and tweaks on Firebird.

Hi Pabloj,

I have one question. Because I will meet this company next week. Do you have any good questions that I could ask them about the Database ?. I am more a Network & SAN Hardware specialist. I know a little about Databases, but I would'nt know how to give these guys the correct questions, so that they would be under pressure to fix the problem .

Thanks again

Mark

Please read again this whole thread, it contains a pretty long and comprehensive list of checks.

Hi Pabloj,

so we had the meeting with the Software / Database Company and we have decided that we need more memory in the database Servers ( 8 GB ). Also we are going to split the database, this will give us more performance. I used a tool called TOP on the Firebird database to see the tasks ect... see below.

7:37am up 3 days, 11:19, 1 user, load average: 0,90, 0,62, 0,29
51 processes: 50 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 51,2% user, 6,2% system, 0,0% nice, 42,1% idle
CPU1 states: 1,0% user, 3,1% system, 0,0% nice, 95,4% idle
Mem: 2064684K av, 2053104K used, 11580K free, 0K shrd, 83668K buff
Swap: 2044072K av, 17252K used, 2026820K free 1739612K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
18064 root 15 0 30856 29M 3748 S 57,7 1,4 1:53 fb_inet_server
18046 root 9 0 26136 24M 3760 S 0,0 1,2 0:09 fb_inet_server
18054 root 9 0 23172 22M 3516 S 0,0 1,1 0:01 fb_inet_server
18072 root 9 0 22400 21M 3668 S 1,1 1,0 0:01 fb_inet_server
18124 root 9 0 21788 21M 3720 S 0,0 1,0 0:01 fb_inet_server
18031 root 9 0 21156 20M 3248 S 0,0 1,0 0:01 fb_inet_server
18009 root 9 0 26376 17M 3688 S 0,0 0,8 0:10 fb_inet_server
18135 root 9 0 6836 6836 3696 S 0,0 0,3 0:00 fb_inet_server
18134 root 9 0 6696 6696 3696 S 0,0 0,3 0:00 fb_inet_server
18133 root 9 0 6680 6680 3696 S 0,0 0,3 0:00 fb_inet_server
18132 root 9 0 5496 5496 3720 S 0,0 0,2 0:00 fb_inet_server
18136 root 9 0 4720 4720 3292 S 0,0 0,2 0:00 fb_inet_server
18084 heron 9 0 1356 1356 1076 S 0,0 0,0 0:00 bash
18040 postfix 9 0 1192 1192 960 S 0,0 0,0 0:00 pickup
18118 heron 9 0 1068 1068 860 R 0,0 0,0 0:00 top
791 root 9 0 3396 792 412 S 0,0 0,0 0:09 miniserv.pl

Rgds

Mark

database slow it could be:
1) no index on 'where' or 'goup by' fields
2) row too large
3) records too much

is there any way to do table horizontal partitioning in database ?


Improving Database Performance with Partitioning (mysql 5.1)
http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Hi all,

For information, we encounter the same performance problem with Firebird and Windows Server 2003.
Here are some tests we have made on the same machine
Hardware:
3GHZ Hyper threaded CPU.
Local Hard Disk.

First configuration :
Firebird Server 1.5 SuperServer (latest release). Default Configuration
Application hosted on the server to avoid any network latency.
Application request : about 8 seconds.

Second configuration :
We uninstall FBServer to Interbase 7.1 Server. Default configuration, same application.
Application request : about 3 seconds.

Third configuration :
We install configuration 1 on a same hardware PC, but with Windows XP Professional.
Application request : about 3 seconds.

Accessing thru the network the database doesn't affect significantly the overall db performance.
Bypassing the use of the hyperthreading in the conf file doesn't affect db performance.

In the first configuration, CPU is used up to 25%...

We are still investigating, but it's seems to be more an FB/OS issue than a hardware one...

Any suggestion ?

Hi NepherK, you should really post this to the Firebird-devel mailing list.

For information i found out the problem, but not solved it :

This is a hardware issue, using a RAID card on the system. Firebird is affected as soon as i have a RAID SATA or SCSI card installed on the system (even if i don't use it), while Interbase 7.1 don't...

Now i can post on firebirds-devel newsgroup..