Results 1 to 3 of 3
  1. #1
    Join Date
    Jul 2009
    Posts
    2

    Unanswered: Firebird 2.1 Optimization

    Hello all,

    I am working with a complex system which uses Firebird 2.1 64bit superserver. We are having some performance problems with the system and are researching the best solution. What I have found so far is that turning off the sweep and doing manual sweeps when the database doesn't have much movement would be one of the main solutions to this. Also possibly forcing the server to use the memory rather than the disk cache would be another solution.

    Just to have an idea of the problem, our system has 8 different programs which access the database. We use 3 Delphi programs, 3 programs in C, 1 program in Python and a third party database explorer for creating procedures and doing database maintenance (ibExpert). The database is accessed by many people at the same time, usually there is one peek time where there is lots of access, which causes many performance problems.

    Our firebird server is located on a dedicated server with 8GB of memory running in Debian Linux 64bit with a powerful processor, so processing shouldn't be a problem, yet sometimes, a simple select can take a long time to return, seems like it's a processing problem. For example, we use a temporary table to receive information, then one of our C based programs calls a procedure to process the information, this process selects the info, fills in some other information from related tables, and then inserts the new information in a new table, and deletes the old information. This process can take 20 minutes to complete, and I am dealing with a table with about 20 tuplas, each of the 20 tuplas having about 500 tuplas in another table which are updated. So it's not loads of information, but it's taking too long to process.

    Another performance issue is when remotely accessing the database, simple actions have a long lag between action and response, a select on the local copy on an inferior server returns instantly where the same select can take a minute to return when accessing remotly.

    What I would like to know is if anyone can give me some ideas of what I can do to better the performance of the server.

    Thanks for any insight.

    Darryl

  2. #2
    Join Date
    Sep 2009
    Posts
    39
    How I in order that resolve problem.

    To buy two extra servers.
    existing and new one put in the replication
    established to serve the insert and delete, and the replication of this small select that record back to 20.
    in each table to add datestamp on second server.and every day to process data for yesterday.
    take some ETL for data processing, the third to create the database for reports from the treated data.
    with the ETL process data and insert into the base on a third server.
    third server can contain more databases.
    when you select and filetered by date for one day on second server, this is very fast because you don't have more 100 k records in one table for each day.



    field date in second server must be indexed.

    sory for english.

    for etl using pentaho or MS tools for business inteligence.
    comming with sql server.

    Pentaho Commercial Open Source Business Intelligence Kettle Project

    support about 35 databases.

  3. #3
    Join Date
    Mar 2009
    Posts
    24
    Quote Originally Posted by darryl.sibeon
    I am working with a complex system which uses Firebird 2.1 64bit superserver.
    You'd better use classicserver if you have 8 core and a lot of RAM.

    Quote Originally Posted by darryl.sibeon
    Another performance issue is when remotely accessing the database, simple actions have a long lag between action and response, a select on the local copy on an inferior server returns instantly where the same select can take a minute to return when accessing remotly.
    You can try Zebedee : http://www.firebirdsql.org/downloads...ebedee_eng.pdf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •