ABAKUS

Das Problem kenn ich.
Bei mir kam dann immer die Meldung "Tabelle in Benutzung".
Konnte nicht mehr drauf zugreifen.

Beim Repair fehlte dann schon mal was.
Seit dem mach ich per Cron täglich ein "Optimize" seit dem gab es den Fehler nicht mehr.

Vielleicht hilft es, oder es ist nur zufall.

soviel ich weiss wird ein table unter myisam als crashed markiert wenn datensaetze korrupt sind. da diese nichtmehr repariert werden koennen werden sie geloescht.
tables mit vielen schreibzugriffen solltest du moeglichst als "memory"-tabletype definieren; kannst du beim start und stop des servers dann ja trotzdem via "create table membackup as (select * from memorytable)" speichern und laden.
nachteil ist das du dann veschiedene datentypen nicht verwenden kannst, text- und blobs gehen dann imho nicht.

@iceman: sehr schoener tipp, werde das mal austesten.

@nerd: die tables sind jetzt bereits schon zweigeteilt, genau wie du andachtest. irgendwann muss ich aber das vom memory ja rausschreiben, und genau dann scheint es manchmal zuviel auf einmal zu werden

Airport1 hat geschrieben:Was liegt vor:
php5, mysql5. viele schreibzugriffe.

Was passiert:
ab und an ist eine mysql table (und zwar die wo die vielen schreibzugriffe landen) als crashed markiert.

Folgefehler:
fuehrt man nun ein REPAIR table aus (wahlweise auch myisam repair tools..) gehen meist 1-2 Datensaetze hopps, d.h. die sind nach dem REPAIR einfach nicht mehr da, quasi wie von zauberhand geloescht. Vom Gefuehl her oft sogar die die besonders viele Schreibzugriffe haben.

Was kann man hier tun, wo sollte man ansetzen, hat jemand eine Vermutung warum die Tabelle so oft crashed (Schreibfrequenz?) bzw. was eine gute Taktik dagegen waere? waere innodb eine alternative, oder eine andere config?

Um das Problem in griff zu bekommen gebe bitte mal noch an, es gibt ja viele Möglichkeiten das Problem in den griff zu bekommen.

- Wird aus der Tabelle viel gelesen?
- Wird in der Tabelle mehre Updates gemacht?
- Wie viele Indexes gibt es?
- Gibt es Indexes über mehre Spalten?
- Was passiert mit den geschrieben Daten?
- wie viele Einträge hat die Tabelle und wie hoch ist der Speicherplatzverbrauch?
- Wie viele Felder hat die Tabelle bzw. was sind für Tabelle Typen verwendet wurden ?

Meist kommt es vor das eine Tabelle crashed, wenn geschrieben/update und gelesen wird in Massen und viele Einträge in der Tabelle sind. Habe es auch oft wenn der Server eine Rebot macht oder der Überhang zu groß geworden ist durch das Löschen von Datensätzen.

Grüße Nico

Outman hat geschrieben:Meist kommt es vor das eine Tabelle crashed, wenn geschrieben/update und gelesen wird in Massen und viele Einträge in der Tabelle sind. Habe es auch oft wenn der Server eine Rebot macht

Wenn ein Rechner neu startet, meldet er das rechtzeitig an alle laufenden Programme, damit sie sauber runterfahren können. Datenverlust bei Neustart kann es so gesehen schlichtweg nicht geben.
Davon abgesehen ist ein kompletter Neustart selten nötig, bestenfalls ein-, zweimal im Jahr, und das auch nur zwangsläufig, nämlich dann, wenn das Betriebssystem ein Update bekommt. Grundsätzlich muss jeder ordentliche Server ewig durchlaufen können, ansonsten ist was faul.
Neustarts sind vielleicht bei heimischen Spielzeugcomputern normal, aber nicht bei Servern, und schon gar nicht, wenn sie von alleine passieren.

Wenn dein Server neu startet, womöglich auch noch alle Nase lang und von selbst, und dabei Daten verloren gehen, dann ist das Problem nicht MySQL, sondern die Kiste selbst ist einfach schrott. Rumdoktern an MySQL wäre da nur Rumdoktern an den Symptomen.

ab und an ist eine mysql table (und zwar die wo die vielen schreibzugriffe landen) als crashed markiert.

Du solltest das Kapitel Optimierung in der MySQL-Anleitung durcharbeiten, vielleicht findest du dort die eine oder andere Idee, mit der du MySQL die Arbeit etwas erleichtern kannst. Es scheint ja so, als wenn die Tabelle bzw. MySQL quasi überrannt wird (obwohl auch das eigentlich nicht passieren dürfte).

Mork vom Ork hat geschrieben:

Outman hat geschrieben:Meist kommt es vor das eine Tabelle crashed, wenn geschrieben/update und gelesen wird in Massen und viele Einträge in der Tabelle sind. Habe es auch oft wenn der Server eine Rebot macht

Wenn ein Rechner neu startet, meldet er das rechtzeitig an alle laufenden Programme, damit sie sauber runterfahren können. Datenverlust bei Neustart kann es so gesehen schlichtweg nicht geben.
Davon abgesehen ist ein kompletter Neustart selten nötig, bestenfalls ein-, zweimal im Jahr, und das auch nur zwangsläufig, nämlich dann, wenn das Betriebssystem ein Update bekommt. Grundsätzlich muss jeder ordentliche Server ewig durchlaufen können, ansonsten ist was faul.
Neustarts sind vielleicht bei heimischen Spielzeugcomputern normal, aber nicht bei Servern, und schon gar nicht, wenn sie von alleine passieren.

Wenn dein Server neu startet, womöglich auch noch alle Nase lang und von selbst, und dabei Daten verloren gehen, dann ist das Problem nicht MySQL, sondern die Kiste selbst ist einfach schrott. Rumdoktern an MySQL wäre da nur Rumdoktern an den Symptomen.

tut mir leid Du hast absolut keine Ahnung, wenn man mit Datenbanken arbeitet die 1,5 Gb groß sind sieht es ein wenig anders aus und wenn eine Server überlastet ist kann es passieren das Du nicht mehr auf das System kommen wirst. Dann musst Du den Server neu starten. Es ist normal bei kleinen Seiten das der Server ohne Probleme ewig läuft, aber nicht wenn man eine Seite hat wo täglich 20000 Leute und mehr unterwegs sind, da kann es schnell zu ganz andern Problemen kommen und die last geht hoch.

Outman hat geschrieben:

Mork vom Ork hat geschrieben:Neustarts sind vielleicht bei heimischen Spielzeugcomputern normal, aber nicht bei Servern, und schon gar nicht, wenn sie von alleine passieren.

Wenn dein Server neu startet, womöglich auch noch alle Nase lang und von selbst, und dabei Daten verloren gehen, dann ist das Problem nicht MySQL, sondern die Kiste selbst ist einfach schrott.

tut mir leid Du hast absolut keine Ahnung, […] wenn eine Server überlastet ist kann es passieren das Du nicht mehr auf das System kommen wirst. Dann musst Du den Server neu starten.

LOL, anstatt einen (oder mehrere) Server einzusetzen, der mit der Last fertig wird, lässt man ihn lieber regelmäßig ins Koma fallen und Daten verlieren. Klar. Völlig normal. Sehr professionell.

Es wundert mich nur, dass Google oder Heise immer erreichbar sind, oder meine Bank nie Buchungen verliert, denn das müsste bei deren Last ja eigentlich normal sein. Aber da sind wahrscheinlich Leute am Werk, die absolut keine Ahnung haben …

Mork vom Ork hat geschrieben:

Outman hat geschrieben:

Mork vom Ork hat geschrieben:Neustarts sind vielleicht bei heimischen Spielzeugcomputern normal, aber nicht bei Servern, und schon gar nicht, wenn sie von alleine passieren.

Wenn dein Server neu startet, womöglich auch noch alle Nase lang und von selbst, und dabei Daten verloren gehen, dann ist das Problem nicht MySQL, sondern die Kiste selbst ist einfach schrott.

tut mir leid Du hast absolut keine Ahnung, […] wenn eine Server überlastet ist kann es passieren das Du nicht mehr auf das System kommen wirst. Dann musst Du den Server neu starten.

LOL, anstatt einen (oder mehrere) Server einzusetzen, der mit der Last fertig wird, lässt man ihn lieber regelmäßig ins Koma fallen und Daten verlieren. Klar. Völlig normal. Sehr professionell.

Es wundert mich nur, dass Google oder Heise immer erreichbar sind, oder meine Bank nie Buchungen verliert, denn das müsste bei deren Last ja eigentlich normal sein. Aber da sind wahrscheinlich Leute am Werk, die absolut keine Ahnung haben …

Bestelle ruhig immer ein neuen Server, dadurch holst Du vielleicht ca. 10 mal mehr Leistung raus und durch eine Script Optimierung kann man 1000 mal mehr Leistung raus holen. So kann man auch sein Geld zum Fenster rauswerfen ...

Es ist halt so das man wenn man nicht eine Optimales Script im Einsatz hat und von Heute auf Morgen das Doppelte am Traffic hat durch z.b. eine bessere Platzierung bei den Suchergebnise und dann ist der Server down, was machst Du, gleich ein neuen Server bestellen?

Bestimmt nicht, sondern Du gehst auf Ursachenforschung und musst den Server neu Starten. Die Daten sind futsch zum teil und man versucht das Problem zu lösen.

Outman hat geschrieben:Es ist halt so das man wenn man nicht eine Optimales Script im Einsatz hat und von Heute auf Morgen das Doppelte am Traffic hat

Jaja, völlig richtig … Der Server stürzt andauernd ab (Zitat: "Habe es auch oft") und verliert dabei auch noch Daten, aber sich mal vorausschauend darum zu kümmern, dass die Kiste mit dem angeblichen Wachstum mithält, womöglich gar aus vergangenen Fehlern lernen - nee, wo kämen wir da hin.

dann ist der Server down, was machst Du, gleich ein neuen Server bestellen?

Klar, wenn mein Kind in den Brunnen gefallen ist, bestelle ich mir ein neues Kind. Und wenn das auch in den Brunnen fällt, sowas passiert ja oft, gibt's das nächste.

Die Daten sind futsch zum teil und man versucht das Problem zu lösen.

Unter einem verantwortungsbewussten Menschen vom Fach verstehe ich jemanden, der es gar nicht erst zu Problemen kommen lässt, jedenfalls nicht derart, dass er zugeben müsste, es würde "oft" passieren.

muss man sich bei kabra eigentlich immer kloppen? bringt doch nix.
ich verstehe beide schienen und man kann sogar beide schienen fahren.

hatte mal scripts probegekauft, die hatten keinerlei indexe ueber die datenbank gelegt. man kann also durchaus auch 2 server mit einem lahmen script bzw. schlechten db zur verzweiflung bringen

man kommt aber durchaus auch ab und wann an den punkt wo das bestoptimierteste script nicht mehr wieterhilft und man wirklich mehr als 1 server braucht. die imdb oder amazon bspw. koennte man sich schwerlich auf einem server vorstellen..

beide habt ihr also in gewisser weise recht, daher nicht kloppen

Zitat: "Seit dem mach ich per Cron täglich ein "Optimize" seit dem gab es den Fehler nicht mehr. "

Ich habe in meiner (damaligen) Zerweiflung nach jedem Schreibzugriff (gleich auf welche Tabelle) ein 'Optimize Table' in meinem Code eingefügt, seitdem keinen Ärger mehr (Performanceverlust erstaunlicherweise im zweistelligen Millisekundenbereich).

Der Delfin schwächelt seit 5.xx an manchen Stellen sogar mit Speicherüberläufen ... mmmpff.


Gruss


codemonk

Wie wäre es mit nem memcache daemon oder ähnlichem, und lediglich alle x minuten die daten rausschreiben...

@everflux

Klar, da kann viel optimiert werden, und wenn es um richtig Traffic und Verfügbarkeit geht, auch investiert werden, aber wie helfen sich WebPack-User?!

Wenn der 5er Delfin rumzuckt?! Und der Support aus Verzweiflung letztlich mit?


Gruss


Codemonk

Warum sollte ich bei "richtig viel Traffik" und einer Anforderung an hohe Verfügbarkeit ein Webpack Kunde sein?