wahsaga: mySQL-Queue läuft über

Beitrag lesen

hi,

Alle Datenbankdaten werden typischerweise von Festplatte gelesen - die häufig benutzten kommen aber vielleicht auch aus dem Cache.

Das mit den Cache stimmt nur teilweise, nämlich dann, wenn die Query absolut identisch ist zu einer Query davor,
http://dev.mysql.com/doc/refman/4.1/en/query-cache-how.html

Wie der URL schon sagt, dass bezieht sich auf den query cache.

Sven sprach aber wohl eher davon, dass der Inhalt einer Tabelle komplett im RAM gehalten werden könnte.

Ich glaube irgendwo gelesen zu haben, daß bei kleinen Tabellen die Tabelle im Speicher bleibt und Updates auf die Platte geschrieben werden.

Eben dieses.

Das das Problem an der Festplatte liegt, da bin ich mir fast sicher. Weil ich meine Probleme löse, wenn ich eine große Menge an Datensätzen aus dieser Tabelle lösche und die Tabelle optimiere.

Dann sag doch lieber, es könnte an der Tabellengröße liegen - denn "die Festplatte" würde ich auf Grund dieser Beobachtung nicht gleich als (Haupt)Ursache sehen.

Ja, vielleicht wird die Tabelle jetzt im Speicher gehalten, weil sie kleiner ist und damit "reinpasst".
Dann ist die Festplatte nur in so fern Schuld, dass Lesen von und Schreiben auf diese natürlich zeitaufwendiger ist, als analoge Operationen im RAM.

Anscheinend ist es so, daß der Apache-Server die Prozesse wirklich parallel abarbeiten kann, wärend der DB-Server nach dem FIFO-Prinzip arbeitet.

Wie Sven schon schrieb: Das _muss_ die DB ja teilweise sogar, wenn für Operationen Tabellen/Datensätze gesperrt werden müssen.

Meist merke ich ja, wenn die Datenbank anfängt in die Kniee zu gehen, die Abfragen dauern dann immer länger, bis zu etwa 30 sekunden.
In dieser Zeit kann ich aber reine HTML-Seiten so schnell wie immer vom Server runterladen.

Die sind ja auch vom Locking auf der DB in keinster Weise betroffen.

Es gibt die Möglichkeit, schreibende Zugriffe zu verzögern (LOW_PRIORITY, DELAYED), in meinem Fall wäre das sogar anwendungslogisch kein Problem (es wäre eins, wenn zB die nächste Seite in einer Handlungsfolge auf die geänderte Tabelle aufbauen würde).
Jedoch treten meine Probleme schon beim reinen Lesen auf.

Es könnte ja sein, dass die Lesezugriffe eben deshalb warten müssen, weil von einem anderen Request gerade ein Schreibvorgang ausgelöst wurde.
Da könnte verzögertes Schreiben also u.U. schon was bringen.

Und wenn du sagst,

Indezes sind eigentlich ausgereizt, wo fast nur lesend zugegriffen wird habe ich schon 2-3 Indezes.

  • auch das kann ja eine zusätzliche Bremse darstellen, wenn im Rahmen jeder Schreiboperation auch noch die Indizes aktualisiert werden müssen.

gruß,
wahsaga

--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }