Überarbeitung des Prozesskillers
Uberspace ist eine Shared Hosting-Umgebung, bei der alle nach gewissen Spielregeln spielen müssen. Es liegt in der Natur der Sache: Ressourcen auf unseren Servern sind - wie überall - begrenzt (wenn auch sehr großzügig dimensioniert) und ab und zu müssen wir der Fairness wegen eingreifen. Das gilt zum Beispiel, wenn ein einzelner Prozess überproportional viel RAM belegt - hier kommt unser Prozesskiller ins Spiel.
Den Prozesskiller gibt es schon lange. Anfangs werkelte er stillschweigend bei uns im Hinterzimmer, seit einiger Zeit verschicken wir auch Mails, wenn wir einen Prozess beenden. Bisher gab es bei 500MB RAM-Belegung eine Warnmail, dass wir den Prozess bald beenden werden, und bei 600MB RAM-Belegung den Abschuss und eine entsprechende Nachricht im Posteingang. Jeder, der schon einmal eine Mail mit einem ähnlichen Betreff wie
“[critical]: Wir mussten deinen Prozess »cmake« beenden”
erhalten hat, hat schon Bekanntschaft mit unserem Prozesskiller gemacht.
Unsere Erfahrung hat gezeigt, dass die bisherige Vorgehensweise zwei Probleme mit sich bringt:
Die Warnmails sind sinnlos.
Der RAM-Verbrauch des Prozesses ist ja nicht unbedingt bewusst von unseren Usern steuerbar. Auf Rückfragen auf die automatisch generierten Mails konnten wir meistens auch nur mit Schulterzucken antworten - auch wir kochen ja nur mit Wasser und können höchstens mutmaßen, dass es wohl irgendwo ein Speicherleck geben muss oder die Software unsauber programmiert ist oder … einfach viel Arbeitsspeicher braucht.
Die Lösung für dieses Problem ist einfach: Es gibt ab sofort keine Warnmails mehr, nur noch die Mails beim tatsächlichen Killen des Prozesses.
Die Werte sind zu unflexibel.
Für die allermeisten Prozesse reichen 600MB an Arbeitsspeicher massig aus. Wenn ein Prozess dauerhaft mehr als 600MB RAM benötigt, ist Shared Hosting die falsche Lösung. (hust Java hust). Es gibt aber eben auch Prozesse, die für eine kurze Zeit mehr Arbeitsspeicher benötigen. Allen voran: Kompilieren von Quellcode (wir haben bereits darüber gebloggt). Aber z.B. auch PHP, was bei uns ja im Kontext des Users per FastCGI läuft, wird sehr speicherhungrig, wenn ein Crawler einer großen Suchmaschine vorbei kommt und ordentlich Seitenaufrufe generiert.
Um dieses Problem anzugehen, mussten wir schon etwas tiefer in die Trickkiste greifen und haben uns folgende Lösung überlegt: Jeder Prozess darf für 10 Minuten maximal das doppelte des eigentlichen Limits an RAM belegen. Und weil wir nicht nachtragend sind, vergessen wir nach 20 Minuten, dass der Prozess jemals mehr als das eigentliche Limit an RAM belegt hat. Wenn also ein PHP-Prozess über mehrere Stunden oder Tage läuft und immer mal wieder die bereits erwähnten Crawler vorbei kommen, schießen wir den Prozess nicht ab, sofern er innerhalb des verdoppelten Limits bleibt.
Ob die Zeitfenster sinnvoll sind, wird der Supportalltag zeigen. Vielleicht drehen wir da noch an der einen oder anderen Schraube, dann gibt es hier natürlich ein Update.
TL;DR
Bisherige Regelung:
- Warnmail bei 500MB RAM-Verbrauch
- Abschuss und Mail bei 600MB RAM-Verbrauch
Neue Regelung:
- Abschuss und Mail bei 600MB RAM-Verbrauch
- auf 10 Minuten begrenzte Verdoppelung der 600MB RAM-Verbrauch vor Abschuss.