Zusammenfassung: Moodle Performance-Probleme zum Semesterstart

[Daniel Baumann]

Hallo zusammen

hier eine Zusammenfassung zur Moodle Performance und unserem etwas
holprigen Start ins Herbstsemester 2016..

Management Summary:

  * Moodle in der aktuellen Version macht im Gegensatz zur 2.5 Jahre
    alten Version die wir bis und mit vorheriges Semester benutzt
    haben, signifikant mehr Datenbankzugriffe.

  * Ab Herstsemester benutzen signifikant mehr User die Moodle
    Plattform, was zu Load-Spitzen bei z.B. Unterrichtsbeginn fuehrt.

    Als Vergleich.. innerhalb des Zeitraum seitdem wir Web-Statistik
    mit Piwik machen (2.5 Jahre):

    - intranet.bfh.ch hatte am 19.9.16 ein neuen Tagesrekord mit 20'000
      Pageviews von 5'000 Usern, ein durchschnittlicher Wochentag ist
      1'000 Pageviews von 500 Usern.

    - www.bfh.ch hatte am 14.9.16 ein neuen Tagesrekord mit 12'000
      Pageviews und 4'500 Usern ein durchschnittlicher Wochentag ist
      7'500 Pageviews von 2'000 Usern.

    - moodle.bfh.ch hat fuer die gleichen Tage jeweils 100'000
      Pageviews und 10'000 User. Die einzigen "ruhigen" Tage waren
      letzten Samstag/Sonntag mit jeweils ueber 3'500 Usern und 25'000
      Pageviews.

    Moodle ist, mit riesigem Abstand, die meist besuchte Webseite
    der BFH.

  * Unser Webstack (Apache/PHP-FPM/PostgreSQL) benoetigt jetzt etwa
    Faktor 3 mehr Rechner-Ressourcen (RAM/CPU) verglichen zum
    Herbstsemester 2015.

  * Mit unseren Hardware- (23.9.) und Software-Anpassungen (21.9. und
    26.9.) ist ein fluessiger Moodle-Betrieb nun gewaehrleistet.

  * Mittel/Langfristige Massnahmen zum kontinuerlichen Ausbau von
    Moodle (PostgreSQL Cluster, Web-Cluster) haetten geholfen, koennen
    aber nicht kurzfristig umgesetzt werden und sind nach wie vor fuer
    2017 auf dem Plan.

Wir bedanken uns fuer alle Rueckmeldungen. Insbesondere Meldungen ueber
schlechte Performance haben uns sehr geholfen, die Load-Spitzen zu
einzugrenzen und zu beurteilen.

Wir entschuldigen uns fuer die Unannehmlichkeiten und wuenschen allen
ein gutes Semester.

---

Lange Version fuer die Interessierten..

Ausgangslage:

  * Moodle laeuft als Linux Container innerhalb einer Linux VM auf
    unserer VMware ESX Umgebung (Bern).
    Die Container (rootfs und Daten) werden per NFS von unserem NetApp
    Server (Bern) in die Linux VM eingebunden.

Ursache:

  * Grundproblem ist I/O wait bedingt durch den VMware Hypervisor mit
    NFS
  * Zusaetzliche temporaere Verschlimmbesserung durch zu zeitlich weit
    auseinanderliegenden checkpoints in PostgreSQL
  * Zu wenige apache Verbindungen fuer hohe Spitzen

Wirkung:

  * Moodle konnte am 20.9. kaum und teilweise am 21.9. nur sehr
    eingeschraenkt benutzt werden
  * User haben entweder DB-Connection Fehlerseite (PostgreSQL
    Connection Limit), DB-Connection Timeout (I/O wait), oder gar keine
    Webseite (apache Connection Limit) bekommen.

Nebenbemerkung:

  * Moodle war vom Ausfall der OCSP Server von QuoVadis weil
    entsprechende Linux Konfiguration nicht betroffen.

Massnahmen:

  * kurzfristig:
    - keine notwendig

  * mittelfristig:
    - Hardware-kaufen-oder-wieder-zurueck-VMware-ESX fuer Moodle
      entscheiden, da Moodle nicht auf dem OpenStack Node verbleiben
      kann (brauchen wir fuer OpenStack).
    - JMeter als regelmaessiges Performance-Test Tool fuer Test-Instanz
      einfuehren

  * langfristig (ab Januar 2017 bis Ende 2017):
    - Arbeiten wie geplant aufnehmen fuer PostgreSQL- und
      Web-Cluster.

  * ...und last-but-not-least: es empfiehlt sich, keine Hermes-Kurse
    bei Ferienabwesenheiten des Kollegen zu Semesterbeginn zu machen :)

Zeitlicher Ablauf:

  * 1+2.9: Moodle Migration (Version 2.7->3.1)
    - wir haben Moodle Anfang September von Version 2.7 auf 3.1
      aktualisiert resp. die alte 2.7 Instanz durch eine komplett neue
      Instanz mit 3.1 ersetzt.

    - gleichzeitig haben wir die Datenbank von MySQL auf PostgreSQL
      gewechselt.

    - ausserdem haben wir seit Moodle 3.1, nun ein vollstaendig
      automatisiertes und reproduzierbares Setup: wir koennen ein
      leeres oder befuelltes Moodle "per Knopfdruck" from Scratch
      (preseeding und Git) und komplett non-interaktiv als Linux
      Container neu installieren. Das ist die technische Voraussetzung
      damit wir bzgl. Infrastruktur in Zukunft ueberhaupt weiter
      ausbauen koennen (PostgreSQL- und Web-Cluster).

  * 13.9.: PostgreSQL
    - wir haben als Vorbereitung auf den Studienbeginn die Connect
      Limits erhoeht fuer PostgreSQL

  * 15.9.: PostgreSQL
    - wir haben als Vorbereitung auf den Studienbeginn die RAM
      Zuweisung fuer PostgreSQL erhoeht

  * 15.9.: PHP-FPM
    - wir haben als Vorbereitung auf den Studienbeginn die Connection
      Limits und RAM Zuweisung fuer PHP-FPM erhoeht

  * 16.9.: VMware ESX
    - waehrend des Tages (Einfuehrungstag 1. Semester) hatten wir keine
      Performance Probleme.

    - als Vorbereitung auf den Studienbeginn haben wir am Abend die
      Ressourcen der Linux VM (auf welcher nur der Moodle Container
      laeuft, sonst nichts) sicherheitshalber "verdoppelt", d.h. von
      4 auf 8 CPUs und von 24GB auf 48GB RAM.

      Vorherige Werte:
      + Fruehlingssemester 2014: 2 CPUs, 8 GB RAM
      + Herbstsemester 2015:     2 CPUs, 12 GB RAM
      + Fruehlingssemester 2016: 4 CPUs, 24 GB RAM

  * 17/18.9: alles auf Gruen
    - es ist Wochenende vor Studienbeginn: viele Professoren bearbeiten
      ihre Kurse im Moodle, alles im gruenen Bereich.

  * 19.9.: alles auf Gruen
    - es ist Studienbeginn, geringfuegig erhoehter Load zu den Tagen
      davor, immer noch alles im gruenen Bereich.

  * 20.9.: 1. Knall
    - System ist ueberlastet, zu Spitzenzeiten kaum zu gebrauchen
    - Phillip hat ab jetzt zwei Wochen Ferien, ich bin den ganzen Tag
      abwesend weil Hermes-Kurs
    - Luca nimmt zusammen mit einem IT-Mitarbeiter der ETHZ am
      Abend/Nacht einige PostgreSQL Anpassungen vor, rettet uns fuer
      den Moment.

  * 21.9.: 2. Knall
    - System ist weiterhin ueberlastet, zu Spitzenzeiten kaum zu
      gebrauchen
    - Luca hat ueber Nacht gearbeitet und jetzt Ausschlafs-/Papatag,
      ich schwaenze den 2. Tag des Hermes-Kurs und kuemmere mich um
      Moodle
    - Problem: PostgreSQL waere soweit in Ordnung, aber apache konnte
      nicht mehr genuegend Verbindungen annehmen (wegen mpm_event ist
      das "normale" Limit zwar, fuer BFH-Verhaeltnisse, sehr hoch und
      haette fuer jede andere Seite der BFH bei weitem ausgereicht,
      fuer moodle.bfh.ch aber brauchts noch mehr)
    - es hat dann immerhin doch noch zur erfolgreichen Hermes-
      Zertifizierungspruefung am Abend gereicht

  * 22.9.: I/O wait?
    - Moodle ist normal benutzbar
    - wir stehen kurz vor Abschluss unseres Monitoring-Projekts fuer
      LFE (Infrastructure und Application Monitoring, per Ende Oktober),
      koennen aber Moodle als Applikation noch nicht ueberwachen und
      tappen daher etwas im Dunkeln.
    - nehme Moodle als "einzelnen“ Monitoring-Punkt auf, so dass wir
      wenigstens die wichtigsten Eckdaten sehen.
    - es zeigt sich dass wir einen sehr hohen I/O wait Anteil haben
      (ca. 10%, normal maximal zwischen 0 und 1%).

  * 23.9.: I/O wait..
    - I/O wait bestaetigt sich und bleibt auch ueber Nacht erhalten.
    - Hypothese: es ist allgemein bekannt, dass NFS ueber VMware ESX in
      eine Linux VM wegen des VMware-Netzwerk-Layers einiges an
      Performance einbuesst (gibt Berichte mit Einzelfaellen von ueber
      30% weniger Bandbreite).
    - Um diese Vermutung zu bestaetigen, stoppe ich den Moodle-
      Container und starte ihn auf einer temporaer noch-nicht
      benutzten OpenStack Admin Node (das ist die kleine OpenStack
      Admin Node, im Gegensatz zu den grossen Compute Nodes), mache
      aber sonst bewusst keine Aenderungen am Stack
      (apache/php-fpm/postgresql).
    - Dank NFS resp. shared Storage ist eine solche "Verschiebe-Aktion"
      nur ein "container stop" auf host A, und ein "container start"
      auf host B, die Downtime ist lediglich 2min in der Mittagspause.

  * 26.9.: I/O wait!
    - Uebers Wochenende hat sich gezeigt, dass I/O wait durch die
      Verschiebung von VMware auf Hardware von einem 10-15% Grundpegel
      (bei wenig Load, sonst bis zu Spitzen von 25%) auf unter 1%
      gelegt hat. Die Hypothese bzgl. VMware ESX und NFS scheint sich
      also zu bestaetigen.
    - Zusammen mit der, im Falle von NFS besonders nachteiligen,
      PostgreSQL Konfiguration vom 20.9. (checkpoints auf 0.7
      Empfehlung des ETHZ IT-Mitarbeiters ist zwar fuer HDD/SSD Systeme
      sehr vorteilhaft, ergibt aber bei NFS und einem I/O
      wait-Grundrauschen bei etwas Load sofort I/O Starvation,
      damit sind dann Dienste entsprechend nicht mehr sinnvoll
      benutzbar).

  * 27.9.: PostgreSQL
    - Seit der VMware-nach-Hardware-Verschiebung des Containers hab ich
      bewusst keine der Komponenten des Stacks angepasst um das Problem
      zu isolieren.

      Da das Problem jetzt isoliert ist, hab ich PostgreSQL am fruehen
      Morgen noch optimal auf die Hardware eingestellt.

  * 28.9.: Alles gut
    - Dienstag und Mittwoch war wieder hoher Load welcher ohne Probleme
      vom Server verarbeitet werden konnten.
    - Normalitaet ist wieder hergestellt

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch