Hallo, hier ist weider Brest mit einen kleinen Informationsservice...
Als (momentan) ständiges Mitglied dieser (etwas schrägen) Community fühle ich mich verpflichtet, euch zur Seite bei euern Problem zu stehen....
Es geht darum, die Datenbank zu optimieren, damit das Server-Problem behoben wird (oh nein, nicht schon wieder!!!)
Also als erstes will ich mal einige kurze Anmerkungen machen:
Seit der Version 3.23 wurde der Typ MyISAM in MySQL eingeführt, davor war es nur ISAM...diese Art von Tabellentyp macht MySQL erst schnell (MyISAM ist gemeint). Beschäftigt euch mit dem Thema MyISAM für MySQL und ihr werdet euer Problem besser verstehen.....mehr will ich nicht auf diesen Typ jetzt eingehen!
Eine Konvertierung zu MyISAM sähe übrigens so aus:
ALTER TABLE table_name TYPE=MYISAM;
Ach ja, Operationen in MyISAM sind atomar, was soviel bedeutet, daß jedes einzelne statement sofort ausgeführt wird und nicht mehr zurückzunehmen ist...bei einer Veränderung wird ein sog. "Lock" auf die gesamte Tabelle angelegt, was ja eigentlich auch ziemlich gut funzt....wenn es das schöne Wörtchen aber nicht gäbe!!!!
Nun gut - ermitteln wir erstmal systemkritische Größen. Dat janze wird über den SQL-Befehl SHOW STATUS getätigt.....
Schaut auf folgendes Ergebnis bei der Ausgabe:
Table_locks_immediate ..... Table_locks_waited .....
Nun wägt diese beiden zahlen in Prozent auf, falls mehr als 5% warten müssen - ist da eine kritische Größe evtl. schon erreicht!!!!
UND GENAU HIER KÖNNTE EIN PROBLEM VORLIEGEN.....!!!!!!!
Was tun, was nun (keine Sorge, ich will net klincken putzen).....
Also erstmal erklärt: Bei geringer Last (wenig user....schreiben wenig, suchen nicht etc...) is alles korrekt!!! Das ist ja auch gewollt. Nun gut, bei größerer Last findet das Warten nicht gleichmäßig, sondern gehäuft statt, was bedeutet daß zu Spitzenzeiten die Prozessorlast nach oben schnellt und das Antwortverhalten verdammt krass einbricht - kurz: Euere nette Ausrede erscheint! ==>
JETZT GANZ GENAU LESEN:
Also das ganze hängt mit der Sperrung von Tabellen zusammen. Eine Tabelle kann nicht gesperrt werden, wenn darin gearbeitet wird! Alles Klar! Wenn du nun ne Abfrage hast, die relativ lange läuft, muss eine verändernde Operation warten, bis die Abfrage fertig ist (...und hier wird genau der Zähler Table_locks_waited hochgezählt). Jetzt ist die Kettenreaktion perfekt. Jetzt müssen alle NUR LESENDE ANFRAGEN warten, WEIL DIESE GOTTVERDAMMTE OPERATION NUNMAL VORRANG HAT!!!!!!!! KAPISCHE.....
Jetzt kann sich innerhalb nur kürzester Zeit tausende Anfrage stapeln. Die Systembremse is perfekt! YEAH.......
...und weil ihr das ganze erstmal schlucken müsst, erzähl ich euch nen Lösungsvorschlag morgen. Ich bin müde vom vielen Lesen und testen (echt ich hab mich mit vBulletin und MySQL heut ne Weile beschäftigt) und schreiben, daß ich mir ne Mütze Schlaf verdient habe, da ich auch noch morgen rackern darf (ich hasse Kassensysteme!!!!!!!!!!!!!!)........Gute Nacht beisammen (sorry für mein scheiß deutsch....)
Als (momentan) ständiges Mitglied dieser (etwas schrägen) Community fühle ich mich verpflichtet, euch zur Seite bei euern Problem zu stehen....
Es geht darum, die Datenbank zu optimieren, damit das Server-Problem behoben wird (oh nein, nicht schon wieder!!!)
Also als erstes will ich mal einige kurze Anmerkungen machen:
Seit der Version 3.23 wurde der Typ MyISAM in MySQL eingeführt, davor war es nur ISAM...diese Art von Tabellentyp macht MySQL erst schnell (MyISAM ist gemeint). Beschäftigt euch mit dem Thema MyISAM für MySQL und ihr werdet euer Problem besser verstehen.....mehr will ich nicht auf diesen Typ jetzt eingehen!
Eine Konvertierung zu MyISAM sähe übrigens so aus:
ALTER TABLE table_name TYPE=MYISAM;
Ach ja, Operationen in MyISAM sind atomar, was soviel bedeutet, daß jedes einzelne statement sofort ausgeführt wird und nicht mehr zurückzunehmen ist...bei einer Veränderung wird ein sog. "Lock" auf die gesamte Tabelle angelegt, was ja eigentlich auch ziemlich gut funzt....wenn es das schöne Wörtchen aber nicht gäbe!!!!
Nun gut - ermitteln wir erstmal systemkritische Größen. Dat janze wird über den SQL-Befehl SHOW STATUS getätigt.....
Schaut auf folgendes Ergebnis bei der Ausgabe:
Table_locks_immediate ..... Table_locks_waited .....
Nun wägt diese beiden zahlen in Prozent auf, falls mehr als 5% warten müssen - ist da eine kritische Größe evtl. schon erreicht!!!!
UND GENAU HIER KÖNNTE EIN PROBLEM VORLIEGEN.....!!!!!!!
Was tun, was nun (keine Sorge, ich will net klincken putzen).....
Also erstmal erklärt: Bei geringer Last (wenig user....schreiben wenig, suchen nicht etc...) is alles korrekt!!! Das ist ja auch gewollt. Nun gut, bei größerer Last findet das Warten nicht gleichmäßig, sondern gehäuft statt, was bedeutet daß zu Spitzenzeiten die Prozessorlast nach oben schnellt und das Antwortverhalten verdammt krass einbricht - kurz: Euere nette Ausrede erscheint!
==> JETZT GANZ GENAU LESEN:
Also das ganze hängt mit der Sperrung von Tabellen zusammen. Eine Tabelle kann nicht gesperrt werden, wenn darin gearbeitet wird! Alles Klar! Wenn du nun ne Abfrage hast, die relativ lange läuft, muss eine verändernde Operation warten, bis die Abfrage fertig ist (...und hier wird genau der Zähler Table_locks_waited hochgezählt). Jetzt ist die Kettenreaktion perfekt. Jetzt müssen alle NUR LESENDE ANFRAGEN warten, WEIL DIESE GOTTVERDAMMTE OPERATION NUNMAL VORRANG HAT!!!!!!!! KAPISCHE.....
Jetzt kann sich innerhalb nur kürzester Zeit tausende Anfrage stapeln. Die Systembremse is perfekt! YEAH.......
...und weil ihr das ganze erstmal schlucken müsst, erzähl ich euch nen Lösungsvorschlag morgen. Ich bin müde vom vielen Lesen und testen (echt ich hab mich mit vBulletin und MySQL heut ne Weile beschäftigt) und schreiben, daß ich mir ne Mütze Schlaf verdient habe, da ich auch noch morgen rackern darf (ich hasse Kassensysteme!!!!!!!!!!!!!!)........Gute Nacht beisammen (sorry für mein scheiß deutsch....)
