[rudluc]

Gab es Wartungsarbeiten oder so etwas? Stundenlang konnte das Forum nicht aufgerufen werden und auch seit Wochen war die Reaktionszeit des Forums im Browser schon recht langsam.
Nun fluppt es aber rasant!

Korrektur - ein paar Stunden später: leider doch nicht rasant! Aber wenigstens lädt es jetzt wieder.

[Robert Auer]

Ich konnte das SUF auch mehrere Stunden lang nicht aufrufen, aber Hauptsache es geht wieder!

[jrunge]

Zitat von Robert Auer

Ich konnte das SUF auch mehrere Stunden lang nicht aufrufen, aber Hauptsache es geht wieder!

Genau, uud dafür ein dickes Danke an die Macher.

[ddd]

moin,

heute Nacht/früh (irgendwann zwischen 03h und 06h) bliebt das Forum wieder stecken.

Es sind Fehler in der mittlerweile riesigen Tabelle "post" aufgetreten, die ich noch nicht nachvollziehen kann.

Der "repair&optimize"-Lauf ging jetzt beim dritten Mal durch und es läuft, Last ist wieder "grün" (war bei >50, jetzt wie es sich gehört wieder unter 1 )

Es ist mühsam, den Fehler in einer >1GByte großen Tabelle mit über 2 Mio rows zu finden.
Irgendwo gibt es einen post, der Müll enthält. Wird der angesprochen, frisst sich die Datenbank fest und dreht sich im Kreis, nur ein harter kill und restart bringt sie von dieser Selbstbeschäftigung ab.
Wir haben Backups, die sehr lange zurück reichen (bis 2011), der Fehler steckt aber nicht in einem erst kürzlich erstellten post, denn solch ein Klemmer trat schon mal vor Jahren auf. Es bringt daher wenig, mit einem restore (unter Verlust aktueller posts, was ich um jeden Preis vermeiden möchte) einen Fix zu versuchen.

Im Moment läuft alles smooth, ich gurke jetzt akut nicht in der Datenbank rum.

Leider bin ich sicher die nächsten vier Wochen vollständig ausgelastet (12h-Schichten sind seit Wochen "normal") und habe keine Resourcen, da grundsätzlich den Fehler zu suchen zu zu beheben. Resourcen meint hier, ich muss den Kopf frei haben und mich da rein hängen, und brauche dafür ein paar Tage Ruhe. Das kann ich im Moment nicht, es ist absolut zu viel, was brennt.

Daher: seit gnädig mit mir, es laufen Vorbereitungen für einen Umzug auf neue Hardware und dann aktuellere Programmversionen. Geht zur Zeit nur mit niedriger Prio.

-thomas

[kiwi05]

Danke für deine Erklärungen und die Instandsetzung.
Mach dir keinen Kopf, wenn du nicht sofortundgleich den großen „Werkzeugkasten“ auspacken kannst/magst.

[Ditmar]

Zitat von kiwi05

Danke für deine Erklärungen und die Instandsetzung.
Mach dir keinen Kopf, wenn du nicht sofortundgleich den großen „Werkzeugkasten“ auspacken kannst/magst.

Dem schließe ich mich an, Danke für die Arbeit.

[steve.hatton]

Danke für die Erkärung, aber gibt`s eventuell etwas, was die User tun könnten - alte Post löschen um vielleicht zu helfen ?

[aidualk]

Nach einer Woche kommst du ja an deine eigenen posts nicht mehr heran.
Aber vielleicht kann man ja alles was älter als ein paar Jahre ist (vielleicht 5 Jahre?) in irgend einer Form auslagern? Ich sehe manchmal alte posts in einer Art 'Archivversion'. Von dort kann man aber auch wieder ins 'normale' Forum wechseln. Wenn das hilft, könnte man das wechseln ins normale Forum abklemmen, so dass man die alten posts halt nur über die Archiv-Version anschauen kann? (nur eine Idee, ob das die Datenbank entlastet? - ich habe aber davon keine Ahnung )

P.S.: Natürlich vielen Dank an Thomas für die viele Mühe, die du dir machst.

[ddd]

moin,

@aidualk: die Archivversion ist nur ein anderes template, d.h ein "Schlichtansicht" derselben Daten, damit vor allem Suchmaschinen-robots die Inhalte leichter indizieren können. Da ist das ganze "Gedöns" ausgeblendet, d.h. alle Bilder, BB-code usw.
Der Ansatz führt daher nicht weiter.

Für den Server sind 1GB tables und 2Mio rows wirklich kein Problem, maria skaliert locker auch noch auf das 100fache. Aber für mich als Mensch darin einen mglw kaum sichtbaren "Fehler" zu finden ist extrem mühsam

Sie blieb heute nacht wieder stehen

Anhand der logs ist klar, es hängt mit dem Backup zusammen.
ABER: es treten keine Fehler auf! syslog ist sauber, nix zu sehen.

Es geht einfach die Last durch die Decke, der Server und die Dienste laufen alle ohne Fehler, nur ist maria so mit sich selbst beschäftigt, dass sie leider auf Bitten um Auslieferung eines Datensatzes so langsam reagiert, dass alle timeouts lange abgelaufen sind, bis die Daten kommen.

Heute war ich schneller mit der "Reparatur", maria stop, myisamchk, maria start.
Gestern hatte ich beim myisamchk Fehler, heute lief der fehlerfrei durch

Wo steckt der Fehler

Ich suche weiter, als q&d-fix setzte ich einen cronjob rein, der nachts zu der Zeit, wo das Backup eigentlich durch sein müsste, rabiat die o.g. Kommandos ausführt, wenn die Last über einem gewissen limit liegt. Nicht schön, aber dürfte funktionieren.

-thomas

Nachtrag:
das Backup läuft durch, hat heute Nacht zwar länger gebraucht, ist aber komplett und sauber. Normal läuft es ca. 8 Minuten, heute waren es 46 Minuten, gestern (da klemmte ja auch schon) war es nach 8 Minuten durch (läuft immer um 0200).
Mir fiel nur auf, dass der letzte Schreibzugriff auf post um 0159 war.
Also schient das Backup NICHT die Ursache zu sein.

So sieht es im Moment aus, ca. 350 user (die meisten als Gäste), alles easy.
Der aktuelle load liegt unter 1, der 5min av auch, und der 15min-Wert zeigt noch Reste vom Restart und fällt zügig.
Der Server hat 8 Kerne, 7 davon langweilen sich und frösteln.
Die gesamte Foren-SW samt aller tables passt locker in den Hauptspeicher (maria, hier als "mysql" aufgeführt) gönnt sich knapp 2 GByte), man könnte das System aus einer RAMdisk fahren, würde noch mal a'bisserl Performance bringen

top - 11:26:20 up 28 days, 22:23, 1 user, load average: 0.48, 0.49, 2.93
Tasks: 188 total, 1 running, 186 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.8 us, 0.1 sy, 0.0 ni, 99.0 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16376800 total, 14216112 used, 2160688 free, 83916 buffers
KiB Swap: 33553340 total, 12013048 used, 21540292 free, 2954048 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13512 wwwrun 20 0 185112 21408 4544 S 2.993 0.131 0:00.15 httpd2-prefork
13459 wwwrun 20 0 185612 22576 5404 S 2.328 0.138 0:00.39 httpd2-prefork
13525 wwwrun 20 0 182052 18248 4468 S 1.330 0.111 0:00.04 httpd2-prefork
12809 mysql 20 0 1855636 626884 10892 S 0.998 3.828 7:41.10 mysqld
13467 wwwrun 20 0 184628 21168 4784 S 0.333 0.129 0:00.36 httpd2-prefork
13472 wwwrun 20 0 0 0 0 Z 0.333 0.000 0:00.24 httpd2-prefork
13477 wwwrun 20 0 179072 11964 1984 S 0.333 0.073 0:00.01 httpd2-prefork
13478 wwwrun 20 0 185068 20796 4348 S 0.333 0.127 0:00.05 httpd2-prefork
1 root 20 0 37328 3112 1604 S 0.000 0.019 1:18.35 systemd
...

[kk7]

Zitat von ddd

Wo steckt der Fehler

Servus,

dedizierter Server oder VM, dedizierter oder Shared Storage? Was läuft auf der Disk zum fraglichen Zeitpunkt? Wird das Backup lokal oder übers Netz geschrieben?

Und natürlich die Klassiker - was wurde verändert bevor das Problem aufgetreten ist? Z.B. Updates eingespielt (OS, FW, Treiber, DB, …), Konfigurationsänderungen, zeitlich relevante DB-Einträge vor dem ersten Auftreten (dürften keine Millionen sein ), neue User, …