Announcement

Collapse
No announcement yet.

Firebird mit katastrophaler Performance

Collapse
X
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Firebird mit katastrophaler Performance

    Hallo
    ich habe eine Firebird Datenbank (grösse ca. 500MB) auf einem Windows 2003 Server (Dual-Core).
    Jetzt möchte ich die Datenbank auf einen Linux Server umziehen lassen.
    Der Server hat 4 CPU's (XEON) mit 4GB RAM.
    Im ersten Anlauf habe ich (wie auch auf dem Windows Server) Firebird Superserver installiert, alles angepasst und die Datenbank eingespielt.
    Der erste Benutzer hat sich angemeldet, und die Performance war berauschend.
    Ich war zufrieden. Dann haben sich alle 15 Benutzer angemeldet und der Server ging komplett in die Knie. Die Benutzer arbeiten mit einem Warenwirtschaftssystem, und das war nicht mehr benutzbar.
    Nun sind 15 Benutzer ja nicht wirklich viel. Das hat mich sehr gewundert.
    Notfallmässig musste der Windows Server wieder einspringen.
    Nun habe ich mich entschieden, den Superserver zu entfernen und dafür Firebird Classic zu installieren.
    Gesagt, getan. Datenbank aufgespielt. Und jetzt Testweise mal 5 Benutzer darauf zugreifen lassen. Performance ok.
    Nun möchte ich aber ungern nochmal so ein Debakel wie beim ersten Versuch erleben.

    Gibt es eine Möglichkeit, die Datenbank ein wenig zu tunen, vieleicht Buffer Einstellungen oder sowas?
    Intern kann ich in die Datenbank nicht hineinschauen, also keine Tabellen verändern oder Abfragen optimieren. Es handelt sich um ein geschlossenes Programm.

    Hat jemand Ideen oder Tipps für mich??
    Tags: firebird performance
  • #2
    Hallo,

    zu Beginn mal eine einfache Frage: Welche Firebird Version setzt du ein?

    Bzgl. Architektur auf jeden Fall den Classic Server einsetzen, weil dir nur diese Architektur ermöglicht, einen Nutzen aus mehreren CPUs/Cores zu ziehen. SuperServer geht dahingehend gar nicht. Wird sich in 2.5 leicht mit der neuen SuperClassic Architektur ändern und hoffentlich in 3.0 gibt es dazu ganz was neues zu berichten (feingranularer mulit-threaded Server).

    Es gehört dann noch überprüft wie deine Datenbankeinstellungen sind (lass mal gstat -h auf die Datenbank los), ob der Server unterschiedliche Datenbankdateien bedienen muss oder nur die eine. Davon hängt auch ein etwaiges Tuning in Bezug auf RAM Nutzung ab.

    Wird über die Zeit die Datenbank langsamer, dann hat man es vielleicht auch mit dem Problem im Transaktions-Handling in der Client-Applikation zu tun. Auch hier mal gstat -h ausführen und beobachten, wie sich die Transakions-Counter entwickeln.

    lg,
    Thomas
    Thomas Steinmaurer

    Firebird Foundation Committee Member
    Upscene Productions - Database Tools for Developers
    Mein Blog

    Comment

    • #3
      Zudem wird der SuperServer noch an die 1. CPU(Kern) gebunden worden zu sein.

      Comment

      • #4
        so
        es handelt sich um firebird 2.0.4
        ich habe die ausgabe von gstat -h mal beigefügt.
        den werd buffers habe ich hoch gesetzt, ich weiss aber nicht ob die idee gut war.
        welcher wert währe besser?

        Database header page information:
        Flags 0
        Checksum 12345
        Generation 31343
        Page size 4096
        ODS version 11.0
        Oldest transaction 27637
        Oldest active 27638
        Oldest snapshot 27416
        Next transaction 31331
        Bumped transaction 1
        Sequence number 0
        Next attachment ID 0
        Implementation ID 19
        Shadow count 0
        Page buffers 130000
        Next header page 0
        Database dialect 3
        Creation date Sep 7, 2010 12:50:02
        Attributes force write

        Variable header data:
        Sweep interval: 20000
        *END*

        Comment

        • #5
          buffers 130000 ist zu viel für den classicserver, hängt aber von deinem Speicher und der anzahl der connections ab. classic ist aber of mit 1000 bis 2000 wesentlich flotter, wenn deine Festplatte nicht all zu lahm ist. pro connection wird speicher reserviert und zwar buffers * page_size. Bei classic
          und 4k Page_size wären das bei 10 Usern bei dir 130000*4096*10, also 5GB.

          beim superserver wären 10000 bis 30000 ok, mehr bringt meist nicht wirklich vorteile. Da fällt dann auch der multiplikator für die anzahl connections weg beim Speicherverbrauch, aber die anderen CPUs werden eben auch nur begrenzt benutzt, je nach affinität in der conf datei.

          Tip wäre noch ein backup/Restore und damit dann die Page_size auf 8k vergrößern, muss aber nicht sein.

          Die folgende Differenz wirft kein gutes Licht auf den Softwarehersteller
          Oldest active 27638
          ...
          Next transaction 31331
          Da kannst du nichts dran machen, aber das sollte normalerweise der Softwarehersteller erkennen und in seiner Programmierung beheben.
          Da schein alte Transaktionen offen zu bleiben.

          Sonst gibt es so eigentlich nichts zu meckern, ggf mal über sowas wie das hier anchdenken, wenn das System bei euch wichtig ist:
          http://ibexpert.net/shop/pi16/index.html


          gruß
          Holger
          www.ibexpert.com

          Comment

          • #6
            hallo
            ich habe bei dem classicserver die buffers jetzt auf 50000 gesetzt.
            das müsste noch in den speicher passen, denn mehr als 15 verbindungen haben wir nicht.
            seltsam ist, das firebird auf windows um längen schneller als auf linux ist.
            und 15 verbindungen sind ja eigentlich nen klacks.

            oder verbessert sich die geschwindigkeit noch, wenn mit der datenbank gearbeitet werd (caching etc)?

            Originally posted by Klemmo View Post
            buffers 130000 ist zu viel für den classicserver, hängt aber von deinem Speicher und der anzahl der connections ab. classic ist aber of mit 1000 bis 2000 wesentlich flotter, wenn deine Festplatte nicht all zu lahm ist. pro connection wird speicher reserviert und zwar buffers * page_size. Bei classic
            und 4k Page_size wären das bei 10 Usern bei dir 130000*4096*10, also 5GB.

            beim superserver wären 10000 bis 30000 ok, mehr bringt meist nicht wirklich vorteile. Da fällt dann auch der multiplikator für die anzahl connections weg beim Speicherverbrauch, aber die anderen CPUs werden eben auch nur begrenzt benutzt, je nach affinität in der conf datei.

            Tip wäre noch ein backup/Restore und damit dann die Page_size auf 8k vergrößern, muss aber nicht sein.

            Die folgende Differenz wirft kein gutes Licht auf den Softwarehersteller
            Oldest active 27638
            ...
            Next transaction 31331
            Da kannst du nichts dran machen, aber das sollte normalerweise der Softwarehersteller erkennen und in seiner Programmierung beheben.
            Da schein alte Transaktionen offen zu bleiben.

            Sonst gibt es so eigentlich nichts zu meckern, ggf mal über sowas wie das hier anchdenken, wenn das System bei euch wichtig ist:
            http://ibexpert.net/shop/pi16/index.html


            gruß
            Holger
            www.ibexpert.com

            Comment

            • #7
              setz den cache doch einfach noch kleiner, 10000 reicht eigentlich immer beim classic. du solltest auflinux auf jeden fall auch noch mal ein backup/restore mit gbak machen, falls noch nicht geschehen. Wie viel arbeitsspeicher belegen denn die firebird prozesse? Wie viele laufen überhaupt?

              Gruß

              Holger
              www.ibexpert.com

              Originally posted by gnude View Post
              hallo
              ich habe bei dem classicserver die buffers jetzt auf 50000 gesetzt.
              das müsste noch in den speicher passen, denn mehr als 15 verbindungen haben wir nicht.
              seltsam ist, das firebird auf windows um längen schneller als auf linux ist.
              und 15 verbindungen sind ja eigentlich nen klacks.

              oder verbessert sich die geschwindigkeit noch, wenn mit der datenbank gearbeitet werd (caching etc)?

              Comment

              Previous template Next
              Working...
              X