Archiv verlassen und diese Seite im Standarddesign anzeigen : Was war denn mit dem Forum los?
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
19.01.2022, 17:38
Ich konnte das SUF auch mehrere Stunden lang nicht aufrufen, aber Hauptsache es geht wieder! :top:
Ich konnte das SUF auch mehrere Stunden lang nicht aufrufen, aber Hauptsache es geht wieder! :top:
Genau, uud dafür ein dickes Danke an die Macher. :top:
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
Danke für deine Erklärungen und die Instandsetzung.:top:
Mach dir keinen Kopf, wenn du nicht sofortundgleich den großen „Werkzeugkasten“ auspacken kannst/magst.
Danke für deine Erklärungen und die Instandsetzung.:top:
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. :top:
steve.hatton
21.01.2022, 13:49
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 ?
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 (https://www.sonyuserforum.de/forum/archive/index.php/t-144133.html)'. 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 :oops:)
P.S.: Natürlich vielen Dank an Thomas für die viele Mühe, die du dir machst. :top:
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 :shock:
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
...
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, …
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
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 :lol:
chefboss
22.01.2022, 18:38
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
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 :oops: )
@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
22.01.2022, 22:49
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
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
23.01.2022, 18:48
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.