BBB-Server - Maximallast

Hallo,

ich habe zwar kein Monitoring auf unserem BBB-Server bei Hetzner, weiß also nicht wie viele Konferenzen und User da zu Gange waren, aber das war und ist das einzige System, das bei uns heute standhält.
Auch die Landesinfrastruktur mit BBB scheint recht gut mit dem Ansturm klar zu kommen, was ich so lese.

Leider habe ich mit Flipped Classroom auf Moodle gesetzt und bevor ich BBB-Links von Greenlight an die SuS verteilen konnte, war auch der Webuntis-Messenger bei mir down.

Moodle - nach wie vor eigentlich unbenutzbar, auch wenn es zwischenzeitlich mal kurz aussah, als ob es wieder super flutscht.

Webuntis-Messenger:
Auch extrem überlastet. Wer rausgeflogen ist (wie ich) kommt nicht mehr rein, weil der Dienst in unserem Webuntis aneblich nicht aktiviert ist.
Der Versuch den Messenger als Admin in Webuntis wieder zu aktivieren fürht zu einer Fehlermeldung.

Kurios: Mein Handy vibriert dauern wegen neuer Nachrichten im Webuntis-Messenger, aber der Versuch die App zu öffnen erfodert Login und dann kommt die Meldung, dass der Messenger nicht aktiviert sei.

Was ich nach wie vor nicht verstehe, warum manche SuS meine Materialien aus unserer NC laden konnten, die ich auf die Schnelle da hochgeladen und einen Freigabelink verschickt haben, ganz viele aber die Meldung „Server nicht erreichbar“ bekamen.
Liegt das am DNS bei Belwü (Subdomain ist bei Belwü)? :thinking:

Ich komme mir wie schon im Frühjahr vor wie in einem drittklassigen Entwicklungsland. Bei denen ist die Infrastruktur wahrscheinlich sogar besser - auf jeden Fall das Mobilfunknetz. :see_no_evil:

Viele Grüße
Steffen

Hallo,
mein BBB hat eine Auslastung von 50 - 70
Ich würde auch gerne so einen schöne Grafik haben wollen.


Unser BBB ist gleich heute morgen abgeschmiert. Seit dem Update am Sonntag habe ich kein gutes Gefühl mehr.
Grüße Ralf

Hallo Ralf,

da ist unserer ja fast noch im Schlafmodus.

Seit dem Neuaufsetzen mist 2.2.30 habe ich keine Updates gemacht und werde das vor Ende des Homeschoolings auch nicht.
Unser BBB-Server war gestern das Einzige, was durchgängig funktioniert hat.

Untis-Messenger ist seit etwa 8 Uhr nicht mehr wirklich nutzbar, Belwü-Moodle zickt seit 9:15 Uhr auch etwas, sehr lange Ladezeiten, aber noch kein Ausfall wie gestern bereits um ca. 8:00 Uhr.

Hab gleich mit meinen 9ern BBB für Mathe vereinbart. Mal schauen, wie’s klappt.
Aber da Moodle etwas zickt und der Messenger, in dem ich gestern Greenlight-Link und Code versendet habe, gar nicht tut, werden wohl nur wenige da sein :frowning:

Viele Grüße
Steffen

Dein Load ist sehr hoch, meine pendelt zwischen 5 und 10. Wieviel Nutzer hast du denn auf deiner Instanz?

Ich habe noch letzte Woche die aktuellste Version intalliert,
BigBlueButton 2.2.31
gefühlt läuft diese Flotter und stabiler mit weniger CPU Last

Hallo,

ich bin auch sehr zufrieden mit 2.2.31
Gestern haben die Server 320 Leute vertragen: dann wurde der Chat lahm
und ab und zu sind Leute rausgeflogen.

LG

Holger

Einfach an die Anleitung hier halten:
Siehe: All-in-One Monitoring

Achso und ich habe dank der hervorragenden Hilfe hier im Forum folgendes Setting:
1 x Dedicated Root Server SB45

Danke, das werde ich mal testen.
Zum Update: Ich habe erst mittels apt das update durchgeführt und dann noch mittels dem update Skript, das wurde dann aber mit Fehler im Docker nicht zu Ende geführt.
Ich denke, dass ich das neu Aufsetzen muss. :frowning:
Grüße Ralf

Hallo,

bei mir ist die Konferenz gerade einmal abgeschmiert. Ich kam nicht mehr rein uns musste sie beenden und eine neue machen. War aber über Moodle problemlos, auch waren alle SuS gleich wieder drin, nachdem ich sie informiert hatte.

Die Load ist jetzt bei uns sogar „nur“ zwischen 3 und 4, höher als 10 dürfte sie nicht gewesen sein, wenn ich mir die 3 Werte in htop anschau, als die Konferenz abgeschmiert ist.

Selbst wenn 2.2.31 stabiler sein sollte und weniger Last braucht als 2.2.30, ist es imho derzeit kein guter Plan, BBB upzudaten.
Den Stress (und den Unmut) will ich mir einfach nicht geben

  • Greenlight sichern (die SL hat alle KuK verpflichtet, sich da zu registrieren, falls Moodle weiter zickt
  • Update machen
  • wenn was schief geht neu aufsetzen
  • Greenlight zurückspielen
  • hoffen, das alles geht.

Viele Grüße
Steffen

Hallo Steffen,

mir ist am Sonntag mein BBB abgeschmiert, habe da nicht lange rum gemacht und neu aufgesetzt.

Dauer knapp 1.5 Std. für die BBB-Installation.

Bisher läuft er sehr gut.

VG Andre

hallo André,

ich weiß, ich habe vor den Ferien nach missglücktem Update auch neu aufgesetzt.

Aber mir ist ja nicht BBB abgeschmiert, sondern eine einzelne Konferenz, und danach ging’s sofort wieder.

Viele Grüße
Steffen

Hi,
ohne die 90 Posts zu lesen, ein BBB-Server der Landesinfrastruktur schafft locker 1000 Benutzer. Ggf. einfach mal da schauen oder nachfragen, die wissen es doch am besten.
LG
Max

Was für Landes Dinger? :sweat_smile:
Die haben dann eben mehrere Server, darum geht es hier nicht. Scalite kennen wir ja

Hallo,

Ich weiß nicht, wie viele Server die in der Landesinfrastruktur haben, aber in Summe waren da heute um die 110.000 parallel unterwegs.
Allerdings wurde von massiv blechernem Ton und Tonstörungen berichtet.
Diese wurden analysiert, ich weiß aber noch nicht ob gelöst.

Viele Grüße
Steffen

Hallo,

hier sieht man, dass es sogar 126000 waren:

Gerade kam ne Mail von den belwü-admins, die echt super erklären, welche Datenbankanfragen wann, bei welcher Last zum Problem wurden und wie sie es verbessern. So ein Mail finde ich sowas von toll!

Sie haben gerade 112 VMs mit je 50-Moodleinstanzen.

VG

Volker

Bei den LFB-BBBs kommen heute Nacht noch drei Server dazu, 25 sind bestellt, sollen morgen kommen.

Und das war die Mail von den Belwueadmins heute, da haben ein paar Leute sehr viel Arbeit investiert und wollten das auch mal loswerden.

Sehr schoene Mail.

Status der Moodle-Plattform

Aktueller Stand:
Sehr geehrte Damen und Herren,

am Montag (11.01.2021) kam es zu Problemen mit einigen Moodle-Instanzen. Die
Probleme traten unter der bisher größten Last auf, die die BelWü Moodle-
Plattform bisher gesehen hatte. In dem Zeitfenster in dem es Probleme gab,
hatten wir versucht das Problem zunächst schnell durch Verwendung von Teilen
unserer Hardware-Reserven zu erschlagen, um so genug Luft zu haben um die
konkreten Probleme und Engpässe zu finden und zu analysieren.

Da die Probleme bei den meisten Instanzen nicht oder nur in einem bestimmten
Zeitraum auftraten, dauerte diese Analyse einige Zeit. Wir könnten
verschiedene Punkte identifizieren, die nur bei sehr hohen Lastsituationen
sichtbar werden und im Voraus nicht trivial gefunden oder simuliert werden
können.

Wir möchten die aufgetretenen Probleme und unsere technischen Änderungen hier
kurz darstellen.

Das größte Problem lag im Verhalten der Datenbanken. Hier gibt es viele
Konfigurationsparameter an denen justiert werden kann und muss. Einer davon
beeinflusst wie viele Daten im Arbeitsspeicher verarbeitet werden und wann
Daten auf Festplatte geschrieben werden. Die Konfiguration sah vor, dass
möglichst viel im Arbeitsspeicher bleibt, denn Arbeitsspeicher ist schnell
und Festplattenzugriffe können theoretisch früher zum Flaschenhals werden.
Unter der hohen Last waren die seltenen aber großen Festplattenzugriffe
allerdings ein Problem, da die Datenbank hier kurz zum Stocken kommt. PHP-
/Webserverprozesse warten dann auf die Datenbank, und es stauen sich offene
Anfragen an, die danach parallel auf die Datenbank einprasseln. Damit
schaukelt sich das Problem ab einer gewissen Lastgrenze auf und die Instanzen
blockieren.

Die Parameter wurde am 11.01.21 gegen 12:00 Uhr an der virtuellen Maschine
mit den meisten Problemen angepasst. Die virtuelle Maschine und die
daraufliegenden Moodles waren danach sofort mit der gewohnten Performance
erreichbar. Die Parameter wurden im Laufe des gestrigen Tages weiter getestet
und als mögliche Problemlösung angesehen. Am Abend und in der Nacht wurden
die Parameter auf allen Datenbankservern konfiguriert. Heute (Dienstag,
12.01.2021) konnten diese Probleme nicht mehr festgestellt werden.

Ein weiteres Problem ist Datenbank-Locking durch die Moodle-Software.
Bestimmte Teile von Moodle bzw. Moodle-Plugins stellen große Anfragen an die
Datenbanken. Für die Anfragen wird die Datenbank in bestimmten Fällen gelockt
(für andere Anfragen komplett gesperrt), damit müssen andere Prozesse kurz
warten, bis die Datenbank wieder schreibbar ist. Das erzeugt ebenfalls
wartende Prozesse und hohe Last im System.

An einigen Stellen wurden diese Datenbankzugriffe im Moodle-Code verbessert,
sodass sie schneller sind und eine bessere Parallelität ermöglichen. Wir
haben hierfür auch Hilfe von den Betreibern der Moodle-Plattform in Berlin
bekommen. Moodle ist freie Software. Der Quellcode ist offen zugänglich und
kann damit auch gelesen und verbessert werden. Die konkreten Verbesserungen
werden von den Betreibern in Berlin in den offiziellen Moodle-Quellcode
eingepflegt.

Außerdem wurden in den Datenbanken zusätzliche Indizes angelegt. Indizes sind
wie ein Stichwortverzeichnis in einem Buch und sorgen dafür, dass
Datenbankzugriffe auf Kosten von etwas Speicherbedarf schneller beantwortet
werden können. Der größte Flaschenhals bei den Indizes waren die Tabellen des
Moodle-Kalenders, die Datenbankzugriffe erzeugten, die bis zu 40 Sekunden
andauerten.

Um bei höherer Last ein Flaschenhals im Webserver ausschließen zu können
wurde hier auch an Parametern optimiert.

Um die virtuellen Maschinen mit den meisten Zugriffen weiter skalieren zu
können wurden diese Heute um 5:00 Uhr auf größere Server umgezogen. Dadurch
ist es möglich im laufenden Betrieb den virtuellen Maschinen mehr CPU-Kerne
oder mehr Arbeitsspeicher zuzuweisen und auf eine höhere Last zu reagieren.

Die Moodle-Plattform hielt dem Ansturm heute (Dienstag) ohne Probleme stand.
Kleinere Lastspitzen wurden innerhalb kurzer Zeit behoben. Ein kurzer DDoS-
Angriff führte zur Mittagszeit zum Ausfall einer virtuellen Maschine für 5
Minuten.

Um die Last noch besser verteilen zu können kann es in den nächsten Tagen
zwischen 22:00 und 06:00 Uhr zu kurzen Ausfällen kommen.

Die meistgestellten Moodle Fragen haben wir unter
Moodle - BelWü Hilfe zusammengefasst. Die FAQ-
Seite wird bei Bedarf erweitert.

Aktuell betreiben wir auf jeder virtuellen Maschine 50 Moodle-Instanzen.
Insgesamt sind derzeit 112 virtuelle Maschinen im Betrieb.

Mit freundlichen Grüßen
Ihre Webmaster

Status: open
Typ: Ausfall
Beginn: 2021-01-11 09:00
Ende: 2021-01-11 15:00

Beschreibung:
Die Moodle-Plattform hat heute morgen um Punkt 8 Uhr alle Rekorde gebrochen.
Die meisten Instanzen halten dem Ansturm stand.

Nur ein kleiner Teil der Zugriffe sind im Moment langsam (länger als 5
Sekunden), oder werfen eine Fehlermeldung. Diese konzentrieren sich auf
einzelne Server. Einer der Server bekommt DDoS-Angriffe ab und ist deshalb
überlastet. Bei weiteren Servern gibt es aktuell Softwareprobleme, die die
Performance der Server einschränken. Wir arbeiten im Moment daran, die
Probleme einzugrenzen und zu lösen.

Korrektur: die Zugriffe, die derzeit langsam sind, oder Fehler werfen liegen
nicht immer bei 1%, sondern schwanken etwas, je nach Last und Situation.

Den Verlauf dieses Vorgangs können Sie unter folgender URL erreichen:
https://www.belwue.de/trouble-tickets/ticket/208_2021-01-11_09-01-48.xml

Eine Übersicht der Störungsmeldungen finden Sie unter
https://www.belwue.de/trouble-tickets/overview.xml

Hallo,

leider bleibt in der Öffentlichkeit trotzdem hängen, Moodle und dieses komische Open Source Frickelzeug taugt nix.

Da kommt diese Meldung nämlich nicht an, oder es fehlen Kompetenz und/oder Wille, die Erläuterung zu kapieren.

Viele Grüße
Steffen

Was anderes, was sagen eure Speedtests? Hatte heute ein bisschen Sorge, aber das scheint noch Luft zu sein:

./speedtest-cli
Retrieving speedtest.net configuration…
Testing from Hetzner Online GmbH (1.2.3.4)…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by GGEW net GmbH (Bensheim) [189.69 km]: 7.252 ms
Testing download speed…
Download: 787.81 Mbit/s
Testing upload speed…
Upload: 835.93 Mbit/s

Hab den hier verwendet:

Hallo Thomas,

Kann mir jemand sagen, wo ich die maximale Anzahl an User je Raume
erhöhen kann?

es gibt kein Maximum (mir nicht bekannt).

Auch würde mich interessieren, was ihr so schon an maximum bei einem
Raum getestet habt. Da müsste die Last ja deutlich höher sein, als wenn
die User auf mehrere Räume verteilt sind, oder?

ich habe es nicht getestet, sondern beobachtet und durch Rückmeldungen
meiner Kollegen (mit Zeitangabe).
Ichhabe die BBB beobachtet: so konnte ich „erfühlen“ wo das maximum ist.
Bei meinen Core i7 4770 Servern liegt es bei 300.
Bei 320 wirds langsam mit 300 geht es noch.
Ich hatte auf dem einen am Montag auch mal 400: da wurde Ton dann
schwierig und manch eine ist rausgeflogen.
Aber: bei den allermeisten ging es trotzdem: auch wenn chat und geteilte
Notizen sehr langsam wurden.

LG

Holger