warum stirbt mein ganzes Betriebssystem bei 7500 Datensätzen?

[Andreas-Lindig]

Hallo Forum,

jetzt habe ich die ganze Nacht verbracht, um mein System neu zu installieren, weil ich dachte, es sei hinüber. Nun stelle ich fest, daß das ganze System lahm gelegt ist, seit ich gestern ca. 7500 Datensätze in meine mySQL-DB eingefügt habe. Gerade habe ich sie auf meinem neuen System wieder eingefügt und wieder lahmt das System. Wenn ich den mySQL-Server abschalte bzw. die Datensätze wieder lösche, läuft das System wieder. Wie kann das sein? Die Tabellen hatten ein paar hundert KB. Also nicht so massig, außerdem werden die Tabellen doch nicht ständig abgefragt. Ich muß das Programm doch testen können. Was kann ich denn da tun?

Gruß, Andreas

[Axel Richter]

Hallo,

daß das ganze System lahm gelegt ist, seit ich gestern ca. 7500 Datensätze in meine mySQL-DB eingefügt habe. Gerade habe ich sie auf meinem neuen System wieder eingefügt und wieder lahmt das System. Wenn ich den mySQL-Server abschalte bzw. die Datensätze wieder lösche, läuft das System wieder. Wie kann das sein?

Der Grund hierfür kann sein, dass Indextabellen im Hintergrund aktualisiert werden. Beim Enfügen neuer Daten geschieht das, damit die Abfragen später schneller laufen können.

Wie lange hast Du dem DBMS nach dem Einfügen der 7500 Datensätze Zeit gegeben, bevor Du (über)reagiert ;-) hast? Prüfe Deine Tabellenstruktur auf das Vorhandensein von Index-Feldern. Finde heraus, wieviele es sind. Füge zunächst weniger Datensätze ein. Beobachte, ob sich das DBMS wieder beruhigt.

viele Grüße

Axel

[Tom]

Hello,

Der Grund hierfür kann sein, dass Indextabellen im Hintergrund aktualisiert werden. Beim Enfügen neuer Daten geschieht das, damit die Abfragen später schneller laufen können.

Wie lange hast Du dem DBMS nach dem Einfügen der 7500 Datensätze Zeit gegeben, bevor Du (über)reagiert ;-) hast? Prüfe Deine Tabellenstruktur auf das Vorhandensein von Index-Feldern. Finde heraus, wieviele es sind. Füge zunächst weniger Datensätze ein. Beobachte, ob sich das DBMS wieder beruhigt.

Und wähle vor allem das richtige Modell für die Datenbank. Ich bin mir nbicht sicher, aber ich denke, default bei MySQL ist das Tini-Modell und das ist wohl nicht mehr für 7500 indizierte Datensätze geeignet.

Ich finde das Kapitel leider gerade nicht, aber es ist etwas länger
http://dev.mysql.com/doc/mysql/de/index.html

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Axel Richter]

Hallo,

Und wähle vor allem das richtige Modell für die Datenbank.

Modell? Meinst Du die storage engine?

Ich bin mir nbicht sicher, aber ich denke, default bei MySQL ist das Tini-Modell

*g* MySQL ist _schon_ ein _richtiges_ DBMS. Es soll sich durchaus auch bereits im praktischen Einsatz bewährt haben.

und das ist wohl nicht mehr für 7500 indizierte Datensätze geeignet.

Das wäre allerdings praxisuntauglich.

Nein. Die Standard-storage engine in MySQL ist MyISAM. Eine Beschränkung der Datensatzanzahl existiert nicht. Es gibt allerhöchstens eine Begrenzung der Dateigrößen, welche hier aber nicht erreicht wird http://dev.mysql.com/doc/mysql/en/Table_size.html. Allerdings komprimiert MyISAM die Index-Dateien, wodurch natürlich das Einfügen von Datensätzen weiter verlangsamt wird http://dev.mysql.com/doc/mysql/en/MyISAM.html.

Hinzuweisen wäre noch auf die Reparaturmöglichkeiten, wenn das Einfügen wirklich zu einer dauerhaften CPU-Belastung führen sollte. http://dev.mysql.com/doc/mysql/en/MyISAM_table_problems.html

viele Grüße

Axel

[Tom]

Hello,

Und wähle vor allem das richtige Modell für die Datenbank.
Modell? Meinst Du die storage engine?
Ich bin mir nbicht sicher, aber ich denke, default bei MySQL ist das Tini-Modell
*g* MySQL ist _schon_ ein _richtiges_ DBMS. Es soll sich durchaus auch bereits im praktischen Einsatz bewährt haben.

Genau deshalb kann man es ja auch in verschiednen Moellen Konfigurieren, je nachdem, ob man viele kleine Datensätze oder wnige große oder etwas zwischendrin hat. Es gibt in der MySQL-Distribution ein Verzeichnis, in dem liegen die my.cnf für die verschiednen Modelle. Und im MySQL-Handbuch gibt es dazu einen recht länglichen Abschnitt, wo die Options erklärt werden. Leider fine ich beises nicht wieder. Ich such hier schon einige Minuten.

existiert nicht. Es gibt allerhöchstens eine Begrenzung der Dateigrößen, welche hier aber nicht erreicht wird http://dev.mysql.com/doc/mysql/en/Table_size.html. Allerdings komprimiert MyISAM die Index-Dateien, wodurch natürlich das Einfügen von Datensätzen weiter verlangsamt wird http://dev.mysql.com/doc/mysql/en/MyISAM.html.

Es gibt eine Mindestanforderung an den allokierten Arbeitsspeicher und die Swapdateien. Der muss für die Indexe und die internen Locktables und die Recordbuffer (Ergebnistabellen) passend gewählt werden. Das muss in der my.cnf eingestellt werden, wenn die DB größer als "normal" wird.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello Axel,

hier ein Nachtrag für den "Schlauberger":

http://forum.de.selfhtml.org/archiv/2004/6/83094/#m485192

@Andreas:
Lies Dir mal http://dev.mysql.com/doc/mysql/de/Option_files.html durch und dann die Beispiel-Konfigurationen, die Du wahrscheinlich auf Deinem Server unter

/usr/local/mysql/support-files/my-huge.cnf
                                 my-large.cnf
                                 my-medium.cnf
                                 my-small.cnf

findest.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Axel Richter]

Hallo,

hier ein Nachtrag für den "Schlauberger":
http://forum.de.selfhtml.org/archiv/2004/6/83094/#m485192

Hm.

Wie groß ist denn der eingestellte Speicher pro Request in der my.cnf? Standard sind 8MB

Welche der Server System Variables http://dev.mysql.com/doc/mysql/en/Server_system_variables.html soll diesen "eingestellten Speicher pro Request" vorgeben?

was für 1,7 Millionen Datensätze bestimmt nicht ausreicht. Alleine eine Indextabelle auf den Primary Key würde da schon 27MB benötigen

Kannst Du den Zusammenhang zwischen 1,7 Mill. Datensätzen und 27 MB für eine Index-Tabelle auf einen nicht näher definierten Primary Key irgendwie begründen?

Zwischendurch wird swapped, was das Zeug hält. Setze den Speicher auf 64MB hoch und du müsstest, was MySQL betrifft eine Steigerung von mindestens Faktor 10 verspüren.

Als einzig mögliche Veränderung, welche sich auf die Performance beim Einfügen von Datensätzen in eine Tabelle mit indexierten Feldern auswirken würde, käme eine Veränderung von key_buffer_size in Frage. Der Wert hier ist aber stark abhängig vom wirklich physikalisch vorhandenen Arbeitsspeicher. Wenn der Wert zu klein ist, wird der Neuaufbau großer Indexdateien langsam, weil viele Einzeloperationen dafür verwendet werden müssen. Hierbei wird allerdings _nicht_ geswapped. Es passiert alles im wirklichen RAM. Wird der Wert allerdings zu groß (etwa mehr als die Hälfte des physikalischen Arbeitsspeichers), dann wird es noch langsamer, weil eben _dann_ der virtuelle Arbeitsspeicher zur Pufferung genutzt wird. Der Vorteil, der wenigeren Einzeloperationen, wird dadurch mehr als negiert.

viele Grüße

Axel

[Tom]

Hello,

hier ein Nachtrag für den "Schlauberger":
http://forum.de.selfhtml.org/archiv/2004/6/83094/#m485192
Hm.
Wie groß ist denn der eingestellte Speicher pro Request in der my.cnf? Standard sind 8MB
Welche der Server System Variables http://dev.mysql.com/doc/mysql/en/Server_system_variables.html soll diesen "eingestellten Speicher pro Request" vorgeben?
was für 1,7 Millionen Datensätze bestimmt nicht ausreicht. Alleine eine Indextabelle auf den Primary Key würde da schon 27MB benötigen

By den neunen MyISAM Tabellen werden für die tabellninterne Datensatzreferenzierung mindestens 8Bytes benötigt. Davon werden sechs für die Referenzierung und die beiden anderen für den Referenztyp des Datensatzes benutzt.

Ein autoincrement-Key macht nun nix anderes, als seinerseits noch sechs Bytes hinzuzufügen, wobei ich bisher immer nur vier feststellen konnte. Macht zusammen also mindestens 12 Bytes pro Datensatz. Bei 1,7 Millionen Datensätzen sind das 20,4MByte bzw 23,8MByte. Mag sein dass ich mich da verrechnete habe, oder aber jetzt irgendwas vergesse, was noch im Index steht.

Kannst Du den Zusammenhang zwischen 1,7 Mill. Datensätzen und 27 MB für eine Index-Tabelle auf einen nicht näher definierten Primary Key irgendwie begründen?

Nicht näher definiert bedeutet: der schlankste der geht und das ist ein Unique Primary Autoincrement

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas-Lindig]

Hallo beide,

hehe, da war ich wohl mal wieder zu ungeduldig ;-) Jetzt hab ich den Salat und muss alle Programme neu aufspielen und einrichten.

Das Problem war scheinbar etwas anders gelagert: ich habe gewisse Abfragen umgeschrieben und eine erst angefangen und ohne WHERE-Klausel so liegen lassen. Danach habe ich die 7500 Datensätze eingespielt und vergessen, daß eine Seite immer diese gewisse Abfrage im Hintergrund aufruft, die ich eigentlich gerade weiter bearbeiten wollte.

Kurzer Sinn: diese Abfrage verband alle Tabellen ohne WHERE-Klausel und erstellte ein karthesisches Produkt. Bei den paar Datensätzen vorher fiel das nicht weiter auf, jetzt higegen mußte sie ca. 4,8 Millarden Ergebniszeilen ermitteln. Wohl etwas zuviel für meinen kleinen Rechner ;-)

Gruß, Andreas und vielen Dank für Eure Hilfe