[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, …

[ddd]

moin,

war eher eine rhetorische Frage

Ist dezidiertes Blech, alles lokal. Echter root-Server, volle Kontrolle.
Kernel maximal "gestippt" und nur die zwingend notwendigen Pakete installiert. Es gibt keine "Komfortfunktionen" wie php<irgendwas>admin o.ä., da die sicherheitstechnische Scheunentore sind. Es laufen nur die zwingend nötigen Kerneldienste, die DB, der Webserver und ssh ... Nur port 80 und 443 sind extern offen (hinter den gefilterten smb-Ports laufen keine server, ein bisschen Futter für die Attack-bots muss sein ).
Prinzip: Sicherheitslücken in nicht installierten Paketen kann man nicht ausnutzen.

Geändert wurde in den letzten Tagen nix, aber die Idee mit den DB-Einträgen könnte klappen:
die Backups sind komplette sql-Inserts in ASCII, kein Komfort, aber täglich ein kompletter Abzug der kompletten DB. Die kann man diffen, und so viele Änderungen in post und anderen Nutzertabellen gibt es nicht von Tag zu Tag.
Wenn der Murks erst in den letzen paar Tagen passiert ist, könnte ich den so finden.

Wir hatten vor Jahren schon mal ein fast unlösbares Problem mit ähnlichen Auswirkungen: damals lief ein AddOn, was bei Freundschaften die (Luftlinien-)Distanz berechnete. Eigentlich trivial, nur blöd implementiert, berechnete es die Distanz zu jedem(!), der mindestens eine Freundschaft hatte, wenn eine dazu kam ... sowas passiert, wenn Leute programmieren, die von Berechenbarkeit noch nie gehört haben.
Folge: der Aufwand stieg mit jedem neuen Eintrag mit (n über k). Nur durch Zufall als ein User dies machte und merkte, dass quasi im selben Moment die Foren-SW stand -mittlerweile dauert es über 30 Minuten für die Neuberechnung, dabei wurden tables gelockt und der Prozess lief nicht mit den Rechten/der Prio des auslösenden Users, sondern "System"Prio-, haben wir das gefunden. Ist deaktiviert, der code lies sich nicht fixen, und die Funktion war nett, aber verzichtbar.

Auch jetzt tippe ich mittlerweile -HW und SW kann ich ausschließen- auf eine Rekursion o.ä.
Leider wird der letzte Zugriff nicht mehr geloggt, und der Zugriff direkt davor hat keinerlei Zusammenhang mit dem Problem. Vmtl. ist der auslösende Zugriff auch nicht der ungeloggte letzte, sondern passiert einige Zeit vorher und es dauert etwas, bis die Rekursion sich so weit hochgeschaukelt hat, dass sich dies in Performanceverlust bis hin zum gefühlten "halt" bemerkbar macht. Währenddessen ist Einloggen auf der Konsole zwar etwas lahm (wenige Sekunden statt normalerweise "instantan"), aber dann läuft die Konsole ohne erkennbare "Bremse", nur der top zeigt loads über 50 und es ist der maria-Hauptprozess, der die Last erzeugt. Würde ich noch warten ginge der sicher auf >100 oder noch mehr, dann wird auch die Konsole irgendwann zäh.
Die sog. "root-reserve" erlaubt aber auch dann noch Eingriffe, und zur Not kann ich den "reset"-Knopf virtuell drücken, dank ext4 ist das Risiko gering und der Server bootet von "PowerOn" bis "ready" in <15s durch.

Ich mache jetzt Lastmonitoring, um den Zeitpunkt des Auftretens genauer zu bestimmen, und dann kann ich in den logs suchen, was direkt davor passiert. Mit etwa Glück findet ich dann den vergurkten Eintrag. Bedenke, syntaktisch und logisch ist der Eintrag korrekt, erst beim Zugriff -mglw mit Zusatzbedingungen- zeigt sich das Problem und wirkt sich erst durch die Foren-SW aus, auf DB-Ebene und darunter ist alles "sauber".

-thomas

[kk7]

Zitat von ddd

war eher eine rhetorische Frage

War mir schon klar Manchmal hilft es, an grundsätzliches erinnert zu werden, um der Lösung näher zu kommen. Mal schauen, ob das so ein Fall wird

[chefboss]

Ich hab zwar keine Ahnung, jedoch ein Gedanke. Könnte es an Firefox liegen? Geschäftlich arbeite ich als Kunde mit SaaS (Software as a Service), welcher seit dem neuen Firefox update bei Daten upload die Kunden jeweils ausloggt.

Gruss, Frank

[ddd]

moin,

das ein Client (= Browser) hier die Ursache ist halte ich für nahezu ausgeschlossen.
Ich schieße jedenfalls mit meinem FF das Forum offensichtlich nicht ab

@kk7: kein Problem, ich erwähne auch immer: Kabel überprüft? (habe mal in einer 50k€-Maschine den Lötkolben angesetzt, es war das Netzspannungskabel, 4h später )

@all: der load-trace ist aufgesetzt und läuft, sollte der 5min-av >10 steigen, wird die DB angehalten, ein tablecheck&repair gemacht und die DB neu gestartet. Das dauert zusammen so ca. 3-5 Minuten.

Während dieser Prozedur kommt dann der VBulletin-Datenbankfehler (blau-weißes Fenster oben links, keine Forenpberfläche), und nach dem Neustart kann es noch für 2-3 Minuten "Datenbankserver ausgelastet" (in der Forenoberfläche) geben.

Ich kann nicht sagen, ob&wann das passiert, es wird aber alles mit Zeitstempel extra mitgeloggt.

jetzt muss ich abwarten und schauen, ob sich im log was zeigt ...

-thomas

[Fuexline]

aber mal im Ernst, was ist das VB 4? schon 5? das ist steinalt und ich kann mir vorstellen das es keinen wirklichen PHP 8.X Support hat, da bleiben dann Zwei Dinge,

1. wenn PHP 7.x läuft wäre das aus sicherheitstechnischer Sicht fahrlässig da dieses Jahr bzw denke schon letztes Jahr der Support dafür eingestellt wurde

2. sollte PHP 8 auf dem Server laufen, würde es mich wundern wenn das Forum generell damit kompatibel wäre.

hat jetzt direkt nicht wirklich was mit dem Problem zu tun, ich will aber nur auf eventuell zukünftige Probleme aufmerksam machen, neue Forensoftware ist besser optimiert, die DB wird vermutlich weniger Ressourcen brauchen - PHP 8, kann Prozesse für jeden Zugriff optimieren - es wäre von Vorteil