[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

[ddd]

moin,

seit gestern 22h ist nix auffälliges passiert:
max 15min-av bei 2.45, 5min-av bei 4.76 und peak bei 7.89. Keine stop-check-start-Sequenz nötig.
Zur Einschätzung: beim "hung" lagen alle drei Werte bei >40 bzw. >50.
Regellast ist <1, beim Backup für 6-8 Minuten maximal 3.
"load" ist ein grobes Werkzeug, reicht aber für diese Zwecke als Schätzeisen.

Das tracing läuft weiter.

@fuexline: Powered by vBulletin® Version 3.8.7 (Deutsch) ... upps, sorry, das ist die Info vom dslr-forum

Wir haben (vor meiner Zeit) die Lizenz erworben, keine Info über Software und Version im Footer angeben zu müssen. Das ist wie auch das Abschalten der Versionsinfo z.B. im Webserver eine von vielen Sicherheitsfunktionen.
Hilft nicht gegen einen gezielten, speziell gebauten Angriff, aber wehrt attack-bots ab, die sich auf solche Infos stützen, um gezielt bekannte Lücken anzugreifen. Diese bots haben so viele targets, dass die sich nicht lange aufhalten, wenn sie die Infos nicht finden, sondern zum nächsten wandern. Ok, ist ein bisschen wie "Sankt Florian, Sankt Florian, verschon' mein Haus, zünd's Nachbarn an". Bei der Masse an bots -wir hatten schon peak >25.000/Tag über Wochen- ist das im Moment die einzige Strategie, den Druck zu vermindern.

Ich fahre das Forum hier wie auch meine dienstlichen Server, das ist Gesundheitsbereich mit höchsten Anforderungen. Wie ich das genau mache, werde ich nur denen darlegen, die Verantwortlich sind (hier ist das der Vorstand des Betreibervereins, also u.a. ich selbst) oder gesetzlich zur Prüfung bestellt. Das SonyUserforum wurde schon amtlich geprüft!

Es ist nicht immer sinnvoll, die alleraktuellste Software mit den letzten patches zu haben, da sind oft die problematischen Sicherheitslücken noch nicht bekannt. Ich bin da mit dem BSI uneins, die bestehen darauf, nur den aktuellsten Stand zu nutzen und immer sofort alle patches einzuspielen. Das ist gerade bei einer großen SW-Firma im Gesundheitsbereich schief gegangen und bei öffentlichen Einrichtungen, Stadtverwaltungen, Ämtern usw.

Anders ist dies bei Systemen, die nicht überwacht und professionell betreut werden: Private, Kleingewerbe, Mittelständler ohne IT-Affinität usw. Für diese Gruppen kann ich auch nur dringend dazu auffordern, alles aktuell durchzupatchen, speziell die Win-Monopol-Clients samt MSO, die Fritzboxen usw.

Das geht nicht gegen Dich, sondern ist in 30 Jahren bewährtes Handeln.

-thomas

[Fuexline]

alles gut!

dennoch, ein Wechsel wird kommen müssen PHP4 nutzt ja auch keiner mehr, einen Plan diesbezüglich sollte man sich machen, glaube das mal erörtert zu haben das man wohl auf VB 5 oder war es 6 gut umziehen kann.