Hohe Speicherauslastung durch ibserver.exe

[H.Neumann]

Hallo Zusammen,

ich habe ein ziemlich dickes Problem, was ich jetzt mal versuche so gut es geht zu schildern:

Ich habe zwei Windows 2000 Server auf Compaq Proliant Rechnern. Jeweils Windows 2000 Advanced Server. Beide identisch konfiguriert (A und B).
Auf diesen Rechnern läuft jeweils ein identisches CRM-System in Verbindung mit Interbase 5.6 (bedingt durch das CRM System).<p>
Server A ist nach geraumer Zeit sehr langsam geworden. Das arbeiten im CRM-System (Netzwerkbasiert) war kaum noch möglich. Die CPU Auslastung des Rechners wurde im TaskManager mit 100% angegeben. Nach genauerem Betrachten habe ich festgestellt, dass die Anwendung ibserver.exe
ca. 500 MB Speicher in Anspruch nahm! Auf dem Server B war die Auslastung bei 3 %, ibserver.exe nahm ca. 50 MB in Anspruch.Das war auch immer mein beobachteter Normalwert. Das Problem hierbei ist, dass an Server A absolut nichts geändert worden ist, es sind nur ein paar Tabellen etc. im CRM - System dazugekommen. Jetzt könnte man denken, dass das vielleicht an den Tabellen oder Views etc. liegen könnte. Aber dem ist nicht so.<p>
Weil der Server A sowieso umziehen musste, habe ich ihn neu installiert. Danach waren die Probleme behoben. Die Datenbanken für das CRM - System habe ich einfach kopiert. Seit der Neuinstallation läuft nun der Server A wie geschmiert, wobei ich Interbase nicht verändert oder anders eingestellt habe.<p>
Nun habe ich heute gemerkt, dass Server B auch sehr langsam ist, und siehe da, ibserver.exe hatte stolze 700 MB Speicher!
Ich habe jetzt aber keine Lust, alle 5 Wochen einen 2000 Server aufzusetzten :-(. Ein Update der Datenbank kommt im Moment auch nicht in Frage.<p>
Jetzt meine Frage: Woran zum Teufel kann das liegen. ich habe hier im Forum schon etwas gelesen, dass Interbase in der Version <6.0 eventuell Speicher nicht mehr frei gibt. Aber warum passiert das so plötzlich???
Von heute auf morgen, erst Server A und nun B! Ich bin mit meinem Latein echt am Ende.<p>Ich habe nur beobachtet, dass die als Service installierten Dienste ibserver und ibguardian bei einem Reboot der Servers nicht mehr automatisch beim Windows-Neustart mit gestartet werden. Früher ging dass, die Einstellungen habe ich überprüft, die Startart steht auf automatisch.
Ich habe hier bewusst darauf verzichtet, die Interbase Einstellungen aufzulisten, da es ja gestern noch sauber lief, und ich nichts geändert habe.
Kann das ein Hardwareproblem am Rechner sein?

[Hans-Jörg Oswald]

Versuche mal, einen Backup/Restore Zyklus durchzuführen, ob sich da was ändert. Verwendest du eventuell NetWare

[Thomas Steinmaurer]

Hallo,
<br><br>
wenn die Datenbank langsamer ist, führ mal folgendes aus:
<br><br>
gstat.exe -h PfadZurDB
<br><br>
Poste einfach alles mal hier herein. Vielleicht sieht man bereits damit etwas, z.B. anhand der OIT/OAT/Next Transaction.
<br><br>
Schöne Grüße,
<br>
Thoma

[H.Neumann]

Hallo Hans-Jörg, hallo Thomas,

vielen Dank erstmal für eure schnellen Antworten.<p>
@Hans-Jörg: Wir haben kein Netware, das Backup/Restore und auch der Sweep werden über Nacht gemacht.<p>
@Thomas: Vorab muss ich sagen, dass das CRM-System 3 verschiedene Datenbanken verwendet:<p>
1. Eine Systemdatenbank (Aufbau und Blätter des CRM)<p>
2. Eine Datendatenbank<p>
3. Eine Abgleichdatenbank (wird für den Aussendiesnst verwendet, damit gleicht der AD seine Daten ab)<p>
Also ich poste hier mal alle Statistiken für alle 3 Datenbanken:<p>
<B>Datendatenbank:</B><p>

Database header page information:
Flags 0<br>
Checksum 12345<br>
Generation 87214<br>
Page size 4096<br>
ODS version 9.1<br>
Oldest transaction 33841<br>
Oldest active 87172<br>
Oldest snapshot 87171<br>
Next transaction 87207<br>
Bumped transaction 1<br>
Sequence number 0<br>
Next attachment ID 0<br>
Implementation ID 16<br>
Shadow count 0<br>
Page buffers 0<br>
Next header page 0<br>
Creation date Sep 2, 2004 14:51:44<p>
<B>Systemdatenbank:</B><p>

Database header page information:
Flags 0<br>
Checksum 12345<br>
Generation 163258<br>
Page size 4096<br>
ODS version 9.1<br>
Oldest transaction 68384<br>
Oldest active 163250<br>
Oldest snapshot 163250<br>
Next transaction 163251<br>
Bumped transaction 1<br>
Sequence number 0<br>
Next attachment ID 0<br>
Implementation ID 16<br>
Shadow count 0<br>
Page buffers 0<br>
Next header page 0<br>
Creation date Sep 2, 2004 14:53:16<p>
<B>Abgleichdatenbank:</B><p>
Database header page information:
Flags 0<br>
Checksum 12345<br>
Generation 468110<br>
Page size 4096<br>
ODS version 9.1<br>
Oldest transaction 8710<br>
Oldest active 466993<br>
Oldest snapshot 466991<br>
Next transaction 468103<br>
Bumped transaction 1<br>
Sequence number 0<br>
Next attachment ID 0<br>
Implementation ID 16<br>
Shadow count 0<br>
Page buffers 0<br>
Next header page 0<br>
Creation date Sep 2, 2004 14:53:27<p>

So, ich hoffe, ihr könnt damit etwas anfangen.
Vielen Dank im voraus.

Gruß

Hendri

[Thomas Steinmaurer]

Hallo Hendrik,
<br><br>
es ist kein Wunder, dass der InterBase Server ordentlich beschäftigt ist.
<br><br>
In allen drei Datenbanken sieht es danach aus, dass mit dem Transaktionshandling der Applikation irgendetwas nicht stimmt, weil Du große Lücken zwischen OIT / OAT / Next Transaction hast.
<br><br>
Nehmen wir den schlimmsten Fall, die Abgleichdatenbank her.
<pre>
Oldest transaction 8710
Oldest active 466993
Oldest snapshot 466991
Next transaction 468103
</pre>
Hier ist Dir eine Transaktion hängengeblieben oder wurde nicht beendet (!) (8710) und seitdem sammelt sich ordentlich etwas an, da Du immerhin schon bei 466993 (OAT) bzw. 468103 (OIT) angelangt bist. D.h., jedesmal wenn eine neue Transaktion gestartet wird, wird für diese Transaktion eine Transaction Inventory Page (TIP) kopiert, die ca. 460000 Transaktionszustände beinhaltet. D.h., der InterBase Server hat einen enormen Verwaltungsaufwand zu vollbringen, um das Ganze am Laufen zu halten. Und, das ist nur eine Datenbank. Bei den beiden anderen Datenbanken hast Du ebenfalls eine Fülle an offenen Transaktionen. Für alle drei gilt, dass sich das bereits nach 22 Tagen angesammelt hat, da die Datenbanken am 2. September 2004 neu aufgebaut wurden (Restore) und unmittelbar nach einem Restore die OIT / OAT / Next Transaction in Ordnung sind.
<br><br>
Was mir in Deiner Info abgeht ist, ob das Sweepintervall auf 0 oder einen anderen Wert gesetzt ist. Sweepintervall ist nichts anderes, dass bei einem Wert von OAT - OIT >= Sweepintervall ein automatisches Sweep angestoßen wird, das jede Tabelle und jeden Datensatz besucht und Datensatzversionen, die nicht mehr benötigt werden, entfernt. Ist Sweepintervall auf 0 gesetzt, dann ist das automatische Sweep deaktiviert und man muss sich darum manuell kümmern, was Du ja mit dem Sweep in der Nacht tust. Dieses Sweep kann allerdings dir Arbeit wieder nur dann ordentlich verrichten, wenn im besten Fall keine Verbindungen zur Datenbank offen sind. Ist das Sweepintervall nicht auf 0, sondern z.B. auf dem Standardwert von 20000, dann könnte es durchaus vorkommen, dass unterm Tag dieses Sweep anspringt und das kann erhebliche Performanceeinbrüche zur Folge haben. Gerade wenn man solche OIT / OAT / Next Transaction Werte hat.
<br><br>
Was könnten die Gründen für die offenen Transaktionen sein, sprich dass OIT und OAT nicht nachgefahren werden können.
<br><br>
- Die Verwendung der BDE im AutoCommit Mode<br>
- Two-Phase-Commit das abgebrochen wurde (z.B. Server- oder Netzwerkausfall) und eine Transaktion sich somit im Status "Limbo" befindet. Solche Transaktion muss man mit gfix.exe beseitigen<br>
- Wenn die OIT nicht nachgefahren wird: Das kann z.B. vorkommen wenn man ein DML Statement, das sehr viele Datensätze betroffen hat, zurücksetzt (ROLLBACK). Bei vielen, spreche ich im Bereich > 100.000. Kann ein Grund sein.<br>
- Wenn die OAT nicht nachgefahren wird: Das kann dann vorkommen, wenn fast ausschließlich nur CommitRetaining in der Anwendung verwendet.
<br><br>
Also, ohne jetzt jemandem auf die Füße treten zu wollen (und mir keine neuen Freunde zu machen :-)), aber ich denke, dass die Anwendung entweder ein schlechtes oder gar kein Transaktionshandlingsdesign besitzt. Vielleicht auch noch in der Kombination mit der BDE.
<br><br>
Das ist meine Ferndiagnose. ;-)
<br><br>
Schöne Grüße,
<br>
Thoma

[H.Neumann]

Hallo Thomas,

vielen Dank für deine superschnelle präzise Antwort. Genau das was du geschildert hast, habe ich mir schon gedacht. Wir vermuten seit längerem, dass es nur an der CRM-Applikation liegen kann.<p>
Ich werde mich jetzt mit dem Softwarehaus mal in Verbindung setzen und die Problematik mit denen besprechen.
Kann ich sonst noch etwas tun???
Ansonsten wünsche ich dir ein schönes Wochenende.

Gruß

Hendrik Neuman

[Thomas Steinmaurer]

Hallo Hendrik,
<br><br>
&gt; Kann ich sonst noch etwas tun???<br><br>
Ja, meinen Namen bei diesem Gespräch nicht erwähnen, außer Sie wollen Hilfe in Anspruch nehmen, die aber nicht kostenlos wäre. ;-)
<br><br>
Zurück zu Deinem Problem: Sofern es sich um keinen 24x7 Betrieb handelt, könntest Du kurzfristig folgendes machen:
<br><br>
- Das Sweepintervall aller Datenbank auf 0 setzen<br>
- Jede Nacht ein Backup und Restore aller Datenbanken machen und mit dem Restore dann einen Tag arbeiten, bis zum nächsten Backup / Restore. Somit würdest Du jeden Tag mit einer frisch zurückgesicherten Datenbank beginnen, die zu Beginn immer gute Werte bzgl. OAT / OIT / Next Transaction aufweist.
<br><br>
Mehr kann ich leider für Dich nicht tun.
<br><br>
Ebenfalls schönes Wochenende und vielleicht sehen wir uns ja nächste Woche auf der EKON8/BorCon2004.
<br><br>
Schöne Grüße,
<br>
Thoma

[H.Neumann]

Hallo Thomas,

natürlich erwähne ich deinen Namen nicht...erst wenn die nicht weiterkommen :-)
Dann kannst du ja Geld verdienen :-)<p>
Also vielen herzlichen Dank nochmal für deine Hilfe.<p>
Gruß

Hendri

[Heiko Luettge]

An Thomas<p>
>> Die Verwendung der BDE im AutoCommit Mode<p>
Wieso ist das ein Grund für das Versagen eines manuellen Sweeps ?
<br>
Es werden doch automatisch Transaktionen erzeugt und commited.<p>
Die Aussage verstehe ich nicht.<br>
Heik