Das gescheitere Update
Ein Drama in drei Akten
Entwicklerkonferenz bei Mojang (Symbolbild)
Ein Drama in drei Akten
Entwicklerkonferenz bei Mojang (Symbolbild)
Wie in der Ankündigung für das 1.14-Update versprochen, möchte ich in diesem Thema unsere Beobachtungen mit der 1.14 beschreiben und einmal darstellen, woran es letztendlich gescheitert ist. In diesem Text werde ich mich auch ein wenig über Mojang, den Minecraftentwickler, auslassen. Dies soll nicht die Entwickler selbst kritisieren, sondern vielmehr das System, wie die Minecraft Java Edition entwickelt wird. Dabei wird auch der Druck seitens Microsoft eine wichtige Rolle spielen.
Dieser Text wird natürlich wieder einige Fachbegriffe verwenden und ein wenig tiefer in die Technik hinter dem Server gehen. Ich versuche aber trotzdem alles so darzustellen, dass jeder es verstehen kann. Für die Profis: Einige Dinge sind selbstverständlich vereinfacht. Falls es Fragen gibt, könnt ihr diese gerne unter dem Thema stellen.
Prolog
Wie in dem Dev-Blog-Beitrag "Hinter den Kulissen Teil 1: Minecraftserver" von @RiotSeb beschrieben, ist Unlimitedworld nicht nur ein einzelner Minecraftserver, sondern besteht aus mehreren, die in einem Netzwerk zusammengefasst sind. Konkret sprechen wir hier über insgesamt sechs Minecraftserver auf denen alleine die Hauptwelt läuft, plus diverse Server für die Farmwelt, die Creative-Welt und die Minigame-Welt. Zu Hochzeiten nutzen wir so bis zu zwölf Minecraftserver parallel. Technisch bedingt kann leider nur eine begrenzte Anzahl von Spielern gleichzeitig auf einem Server sein. Durch unser Netzwerk werden die Spieler auf viele Server verteilt, so dass bei 200 Online-Spielern trotzdem auf jedem einzelnen Server nur ca. 30 bis 50 Spieler sind.
Früher war es so, dass man vereinfacht sagen konnte, dass ein Minecraftserver alle seine Weltberechnungen auf einem einzigen Kern des Prozessors (CPU, Central Processing Unit) durchgeführt hat. Unsere Hardware hatten wir so ausgewählt, dass sie genau dem gerecht wird. Wir nutzen einen Hardware-Server (im weiteren Verlauf als Maschine bezeichnet) mit einem Intel Xeon E5-1650 v4 @ 3.60GHz mit 6 Kernen und 12 Threads (parallele Abarbeitungsmöglichkeiten), 128GB DDR4 Arbeitsspeicher und zwei 1,8TB NVMe-SSDs im RAID1. Auf dieser Maschine laufen natürlich auch das Forum, der Teamspeak, unsere Datenbankserver, unsere Entwicklungsinfrastruktur und einige Hintergrunddienste für die Steuerung und das Monitoring des ganzen Systems.
Durch dieses Hardwarekonzept konnten sich die Minecraft- und sonstigen Server problemlos auf die 12 CPU-Threads verteilen. Das hat bis zur Version 1.12 wunderbar funktioniert.
1. Akt: Die Veränderung
Bis zu diesem Punkt hat ein Minecraftserver vor allem von der Single-Core-Performance profitiert: Eine CPU, die einzelne Kerne (Single Core) sehr hoch getaktet hat, sorgte dafür, dass man dort einen Server mit vielen Spielern flüssig laufen lassen konnte. Ich erinnere mich noch an die Zeit mit der Version 1.10, wo es kein Problem war, 120 Leute auf einem einzelnen Server laggfrei spielen zu lassen.
1. Auftritt: Neue Technik
Jedoch entwickeln sich moderne CPUs eher so, dass sie statt wenigen Kernen mit großer Leistung eher viele Kerne mit weniger Leistung haben. Auch Mojang hat dies gemerkt und ab der 1.12 verstärkt damit angefangen, die Prozesse des Servers zu parallelisieren, sodass ein Server die Leistung von mehreren Kernen nutzen kann. Der Hauptprozess des Servers, der für die Berechnung der Welt, der Tiere usw. zuständig ist, bleibt jedoch weiterhin auf einem Kern. Zuletzt wurde so die Lichtberechnung vom Hauptprozess des Servers in einen Nebenprozess ausgelagert. Das klingt alles super, jedoch ist die Umsetzung einfach unglaublich schlecht. Und mit neuen Minecraft-Versionen kommen immer mehr neue, rechenintensive Inhalte dazu, sodass auch die eigentlichen Aufgaben des Hauptprozesses schon zuviel werden. Hinzu kommt, dass die Parallelisierung so schlecht implementiert ist, dass sie mehr Rechenleistung kostet, als es am Hauptprozess sparen könnte. Natürlich benötigen neue Inhalte im Spiel mehr Rechenleistung, jedoch sorgen die "Optimierungen" seitens Mojang dafür, dass mit jeder Version deutlich mehr zusätzliche Rechenleistung benötigt wird als erträglich ist. Zuletzt konnten man an einem nicht optimierten 1.14-Server erkennen, dass dieser bis zu 50% mehr Prozessorleistung und etwa 30% mehr Arbeitsspeicher benötigte als ein 1.13-Server. Wenn man sich überlegt, wie wenig eigentlich dazu gekommen ist, ist das schon heftig. (In diesem Absatz habe ich absichtlich die parallel laufenden Prozess-Threads als Haupt- und Nebenprozesse bezeichnet, der Terminus stimmt natürlich nicht, macht es aber übersichtlicher.)
2. Auftritt: Unsere Anpassungen
Nachdem wir mit den Anpassungen an unseren Plugins für das 1.14-Update recht schnell fertig waren, legten wir das Augenmerk auf die Optimierung der Minecraftserver. Zuerst hofften wir noch, dass Mojang noch Fixes für die 1.14 bringt, jedoch kündigte Mojang mit dem Release der 1.14.4 an, dass man sich dort jetzt auf die 1.15 konzentrieren wolle und man keine weiteren Performanceupdates für die 1.14 herausbringen würde. Ein Schlag für uns, denn nun waren wir wieder auf uns alleine gestellt. Die Entwicklercommunities hinter der von uns eingesetzten Serversoftware Spigot und Paper haben viele Verbesserungen hervorgebracht, welche wir mit eigenen Optimierungen erweitert haben. Zuletzt waren wir mit unseren Tests so zufrieden, dass wir das Update auf 1.14.4 wagten.
Und genau an diesem Punkt möchte ich einmal auf unsere Beobachtungen eingehen und zeigen, wo die Probleme bestehen.
2. Akt: Der Minecraftserver
In diesem Thema schauen wir uns exemplarisch einen unserer Minecraftserver an, konkret die Zentralwelt ohne Spawn. Dieser Server ist besonders interessant, da er als größter und ältester Teil der Welt immer am stärksten belastet ist. Die folgenden Graphen zeigen als rote Kurve immer die Spielerzahl auf dem Server "Zentralwelt". Die Daten stammen von kurz nach 17:00 Uhr vom Tag des Updates und zeigen die vergangenen 24 Stunden. In der ganzen Zeit sind stets weniger als 30 Spieler in diesem Teil der Welt.
1. Aufritt: Ticks per Second
Mincraft ist ein Tick-gesteuertes Spiel. Alle 50 Millisekunden (ms) wird ein Tick ausgelöst, also 20 Ticks pro Sekunde (TPS). Auch wenn niemand etwas macht, bewegen sich mit jedem Tick die Tiere, wachsen die Pflanzen etc.. Normalerweise kann der Server alle Aufgaben, die er in einem Tick erledigen soll, in den zur Vefügung stehenden 50 ms abarbeiten. Dann läuft er mit dem Idealwert von 20 TPS. Im Normalfall wird der Server mit einem Tick sogar schon nach maximal 40 ms fertig und hat dann 10 ms Pause. Es kann aber auch vorkommen, dass bspw. durch die Berechnung von sehr vielen Tieren der Server manchmal mehr als 50 ms für einen Tick braucht. Der Server kann nicht einfach den Tick abbrechen, aber er kann sich mehr Zeit für den Tick nehmen. Das senkt dann die TPS, d.h. es erfolgen weniger als 20 Ticks pro Sekunde. Hier ist einmal dargestellt, was eine Veränderungen der TPS für das Spielerlebnis auf dem Server bedeutet:
18 - 20 TPS: Der Server läuft gut, Schwankungen kommen ab und an vor, stören aber selten.
15 - 18 TPS: Der Server läuft noch annehmbar, jedoch hängen Tiere und Spieler schon merkbar und Interaktionen finden verspätet statt.
10 - 15 TPS: Der Server läuft schlecht, man muss fast alle Blöcke mehrmals abbauen, der Tagesrhythmus springt.
0 - 10 TPS: Das Spielen auf dem Server ist kaum noch möglich, man wird ständig zurückgesetzt und der Server kann jederzeit abstürzen.
Zusammengefasst sollte also jeder Server mit 18 bis 20 TPS laufen. Jetzt schauen wir uns mal an, wie das mit dem Update aussah (grüne Kurve und linke Skala = TPS, rote Kurve und rechte Skala = Spieler in der Zentralwelt):
Schauen wir uns zuerst den Abend des 07.08. an (linke Seite): In der Spielerspitze gegen 21 Uhr erkennt man leichte Schwankungen der TPS, jedoch bleiben die TPS fast immer über 15, weswegen man keine größeren Einschränkungen beim Spielerlebnis hinnehmen muss. Der Server "Zentralwelt" könnte mit der Spielerspitze besser laufen, aber so ist es okay.
Nach dem Update ist aber plötzlich alles anders: Die TPS fallen mit vergleichbarer Spielerzahl schlagartig unter sieben - zeitweise hatten wir nur 2,48 TPS! Dieser Zustand ist keinesfalls hinnehmbar. Im Graphen erkennt man ganz gut den Restart gegen 14:30 Uhr sowie eine Verbesserung der TPS, als nur noch 10 Spieler auf dem Server waren. (Funfact: Wir überwachen laufend die TPS aller Server und hatten die Graphen so eingestellt, dass die TPS nur zwischen 14 und 22 angezeigt werden, weil sie nie darunter fielen. Daher konnten wir die schlechten Werte anfangs gar nicht sehen und mussten die Graphen nach unten erweitern.)
Woran hat diese rapide Verschlechterung nun gelegen? Üblicherweise können wir die Ursache an den Timings (quasi einer Aufgabenübersicht des Servers) ablesen, doch das war diesmal nicht möglich, da die Auslastung der Maschine über die ganze Zeit kritisch hoch war (siehe 3. Akt). Erkennbar war nur eine sehr hohe Auslastung durch Entities, also vor allem Tiere, besonders auch durch Villager, die seit der 1.14 nicht mehr nur zwei internen Bewegungszielen nachgehen (z.B. Haustür oder Feld aufsuchen) sondern, trotz Optimierungen, über zehn (u.a. Arbeitsblock, Bett und Glocke aufsuchen). Weiterhin kann man sagen, dass die 1.14.4 einfach katastrophal läuft. Viele Informationen deuten darauf hin, dass die Minecraftserver für einige Sachen viel mehr Leistung benötigen als eigentlich nötig wäre. Neben den Änderungen an der Lichtberechnung verursachen scheinbar vor allem auch "Optimierungen" seitens Mojang beim Laden und Entladen von Chunks eine untolerierbare Mehrbelastung.
2. Auftritt: Arbeitsspeicher
Um Welten, Spieler, Tiere usw. im Prozess schnell zugreifbar zu machen, benötigt ein Minecraftserver - wie jede andere Anwendung auch - Arbeitsspeicher (RAM). Ein typischer Irrglaube ist, dass Minecraftserver dabei besonders viel RAM benötigen. Unsere Minecraftserver benötigen üblicherweise nur maximal 4 GB RAM, wobei davon etwa 1 GB von den Daten unserer eigenen Plugins belegt wird.
Mit der 1.14.4 war uns schon bekannt, dass deutlich mehr Chunks geladen bleiben als bisher und jeder Minecraftserver so etwa 30 % mehr RAM benötigen wird. Dies haben wir während des Updates passend eingerichtet. Freie Ressourcen hatten wir glücklicherweise genug. So sah die Veränderung dann im Betrieb aus (violette Kurve und linke Skala = RAM, rote Kurve und rechte Skala = Spieler in der Zentralwelt).
Die violette Kurve zeigt, dass die Belegung des RAMs schwankt. Dies ist ganz normal: Daten, die beim Prozess nicht mehr benötigt werden, wie z.B. ein Chunk, der nicht mehr geladen ist und bereits auf die Festplatte gesichert wurde, werden nicht sofort, sondern später zeitversetzt vom sogenannten GarbageCollector (Müllsammler) freigeräumt. Im normalen Serverbetrieb funktioniert der GarbageCollector so, dass er entweder die freie Zeit zwischen zwei Ticks nutzt, um unbenutzte Daten wegzuräumen oder dass er so weit wie möglich entkoppelt vom Serverprozess funktioniert, um diesen nicht zu stören.
Da aber nach dem Update auf die 1.14.4 zwischen den Ticks keine Zeit mehr übrig blieb und die Auslastung der Maschine auch teilweise zu hoch war, damit der GarbageCollector seine Aufgabe entkoppelt durchführen konnte, kann man an zwei Stellen erkennen, wie der RAM der Zentralwelt bis zum von uns festgelegten Maximalwert von 6 GB gefüllt wird, da der GarbageCollector überhaupt nicht mehr nicht aktiv wurde und keine Daten mehr wegräumte.
Wenn der Speicher bis zu seinem zugewiesenen Limit komplett vollläuft, wird automatisch eine Notfallaktion, der sogenannte FullGC durchgeführt. Dabei wird der Serverprozess angehalten und alle Leistung für das Freiräumen des RAMs benutzt. Das Resultat ist ein sogenanntes Stop-The-World-Event, weil wirklich alles im Prozess pausiert. Bei einem Minecraftserver kann das dazu führen, dass es kurz massiv laggt oder es sogar zu einem Timeout bei den verbundenen Spielern kommt und sie die Verbindung zum Server verlieren. Deshalb arbeiten wir daran, diese FullGCs mit diversen Optimierungen zu verhindern - bei der 1.14 hat das leider nicht geklappt.
3. Auftritt: Weitere Überwachungsparameter
Natürlich überwachen wir noch einen Haufen weitere Parameter für jeden Server. Ich habe hier noch zwei Graphen, die sehr interessant sind.
Zuerst mal ein gutes Zeichen. Hier ein Graph, bei dem die geladenen Entities in orange (Tiere, Monster, Bilderrahmen, Rüstungsständer usw.) und Tiles in gelb (Blockinhalte wie Kisten, Öfen, Trichter usw.) zeigt (gemeinsame Skala links). Die rote Kurve und die rechte Skala zeigt wieder die Anzahl der Spieler in der Zentralwelt.
Hier kann man erkennen, dass es vor und nach dem Update kaum Veränderungen gab. Das ist genau so wie erwartet: Die Anzahl der geladenen Tiere und Blockinhalte hat sich durch das Update nicht verändert.
Weiterhin zeichnen wir auf, wie viele Chunks auf jedem Server geladen sind (gelbe Kurve mit Skala links). Hier erkennt man alleine für die Zentralwelt schon einen großen Unterschied zwischen vor und nach dem Update:
Man sieht deutlich nach dem Update einen Anstieg der geladenen Chunks um mehr als 250 %. Der Grund ist eine Optimierung von Mojang. Früher wurden nur die Chunks innerhalb der Spielersichtweite geladen und getickt (aktive Chunks). Mit Version 1.14 werden weitere Chunks außerhalb der Sichtweite geladen. Diese passiven Chunks bleiben deutlich länger geladen und werden nicht getickt. Deshalb tauchen auch deren Tiere und Blockinhalte nicht oben in dem Graphen auf.
Beim Laden der Chunks haben wir bereits diverse Optimierungen am Server vorgenommen. Jedoch bleibt das weiterhin ein guter Ansatzpunkt: Kann man vielleicht die Zahl der passiven Chunks reduzieren? Gibt es hier noch Fehler, welche den Lastanstieg begründen? Oder haben wir einen Fehler in unseren Optimierungen gemacht? Hier werden wir versuchen, den Server weiter zu optimieren.
3. Akt: Die Maschine
1. Auftritt: Prozessorleistung
Oben habe ich ja schon beschrieben, dass es auch ein Problem mit der Auslastung der Maschine, also mit der Hardware gab. Zu Beginn des Updates auf die Version 1.14.4 haben wir alle unsere Entwicklungsserver heruntergefahren (der Beta-Server und interne Welten, auf den wir Sachen vorbauen und testen). Ebenfalls haben wir Unlimitedworld mit der 1.14.4 mit minimalem Unfang gestartet - also nur mit Farmwelt und Creative-Welt ohne Minigame-Welt - um ein ungetrübtes Bild von den Leistungsanforderungen der 1.14 für den reinen Spielbetrieb zu bekommen und um ihm die maximalen Ressourcen zu geben. Nachdem wir die Tests auf dem Beta-Server umgerechnet hatten, kamen wir zu dem Entschluss, dass wir mit den bestehenden Ressourcen genau auskommen müssten - Pustekuchen:
In der Grafik sieht man die letzten 32 Stunden der Maschinenauslastung aus dem Monitoringtool Munin. Wir nutzen dieses Tool zusammen mit einigen anderen, aber die Munin-Grafiken geben mit Abstand am schnellsten eine Übersicht über das Geschehen. Jeder Prozessor-Thread ist hier mit 100 % dargestellt, sodass wir insgesamt 1200 % (12 Threads à 100 %) zur Verfügung haben. Der dunkelgrüne Bereich zeigt die CPU-Auslastung der Hardware durch das Betriebssystem, der blaue Bereich die Auslastung durch alle unsere Prozesse und der gelbe Bereich ist die Freizeit, die die CPU hat (Idle Time).
Am Tag vor dem Update (Wed = Mittwoch) erkennt man, dass die Leistung der Maschine ausreichend ist. Die Belastungsgrenze wird kurz vor 22:00 Uhr mit 1100 % erreicht. Zu diesem Zeitpunkt waren 150 Spieler online und neben den Spielwelten liefen auch noch alle internen Server.
Im weiteren Verlauf erkennt man das tägliche Backup um 4:00 Uhr als kleine Last-Spitze, dann das Ansteigen der Last durch mehr Spieler am Vormittag des Donnerstags (Thu) sowie die Lastspitze durch das Backup um etwa 12:00 Uhr. Während wir das Update durchgeführt haben, haben wir auch alle Welten für die 1.14 konvertiert, damit dies nicht im Serverbetrieb geschehen muss, was eine weitere Spitze verursacht.
Um kurz vor 14:00 Uhr öffneten wir den Server dann wieder - und innerhalb weniger Minuten stieg die Serverlast massiv an. Zwar ist immer noch ein kleiner gelber Freizeit-Bereich zu sehen, aber das täuscht. Die Messwerte werden über 5 Minuten gemittelt und aus verschiedenen technischen Gründen (bspw. auch Hyperthreading vs. Turbo-Takt) können diese bei unserer Art der Belastung nicht über den Wert steigen, den man oben erkennt. Der Prozessor war also komplett ausgelastet, es war keine Rechenzeit mehr dafür frei, die Ticks gescheit zu berechnen und andere wichtige Berechnungen noch korrekt durchzuführen. Das wäre für eine kurze Zeit auszuhalten, aber dauerhaft verursacht eine solche hohe Auslastung noch andere Probleme. Irgendwann muss man sogar damit rechnen, dass die Lebenszeit der Hardware drastisch reduziert wird.
Unsere Hochrechnungen aus den Beta-Tests waren also nicht korrekt gewesen. Stattdessen benötigt die 1.14.4 mit unserem Entwicklungsstand, also trotz der zahlreichen Optimierungen, immer noch unglaublich viel Prozessorleistung. Für einen normalen Betrieb mit 120 Spielern würden wir in diesem Zustand etwa das Doppelte an Prozessorleistung benötigen, als noch mit der 1.13.2.
2. Auftritt: Arbeitsspeicher
Nun möchte ich noch einmal auf die Thematik mit dem Arbeitsspeicher eingehen, bei der wir glücklicherweise nicht so kalt überrascht wurden:
Auch hier sieht man wieder eine Grafik aus dem Monitoringtool Munin mit den letzten 32 Stunden. Über 80 GB der 128 GB RAM, die wir zur Verfügung haben, werden üblicherweise von den Servern und allen anderen Diensten benutzt (grün). Der Rest ist frei für den sogenannten Cache (dunkelblau). Das Betriebssystem legt Daten, die es häufig von der "Festplatte" lesen muss im freien Teil des Arbeitsspeicher ab, um Zugriffszeit zu sparen. Von diesem Cache profitieren vor allem die Datenbankserver sowie auch die Minecraftserver. Bei unserer Maschine benötigen wir diesen Cache zwingend, da es sonst beim Prozessor zu sogenannten IOWaits kommen würde, also Zeiten, die der Prozessor damit verschwendet, auf Festplatteninteraktionen zu warten (IO = Input/Output, Wait = Warten). Das Betriebssystem hat es ziemlich gut raus, Dateien so im Cache abzulegen, das IOWaits fast völlig verhindert werden können - genau das erreichen wir im Betrieb auch.
Vergleicht man den grünen Bereich vor und nach dem Update, fällt auf, dass die wenigen Server, die in der Minimalversion von Unlimitedworld mit der 1.14.4 laufen, genauso viel RAM brauchen, wie die vielen Server mit 1.13.2. Damit hatten wir gerechnet und die Ressourcen hatten dafür gereicht. Zusätzlich erkennt man, dass das Betriebssystem deutlich aggressiver mit dem Cachen beginnt. Der Cache füllt sich nicht langsam über den ganzen Tag, sondern sofort. (Dies sorgt im übrigen auch dafür, dass in orange ein spezieller Cache, der Slab-Cache, stärker beansprucht wird als vorher). Durch die erheblich größere Menge an Lade- und Entladevorgängen bei den Chunks (siehe oben) hat das Betriebssystem viel schneller begonnen, Daten zu cachen - das hat es so gut gemacht, dass tatsächlich durch die 1.14.4 kein Anstieg der Festplattenbelastung (hier nicht dargestellt) zu erkennen war. Hier kann man also wenigstens von einem kleinen Erfolg sprechen: Arbeitsspeicher und Festplatte haben sich optimal verhalten - genau so, wie geplant.
Hier nochmal eine zusammenfassende Grafik aus dem Tool netdata, in dem wir mit einer eigenen Erweiterung die Auslastungen, die nur von den Minecraftservern kommen, präziser bestimmen können. In diesem Beispiel ein 10-Minuten-Ausschnitt ab 17:00 Uhr am Tag des Updates. Die Grafik zeigt die CPU-Auslastung durch die verschiedenen Minecraftserver, die rechts farblich aufgelistet sind (die Zentralwelt heißt "main_c").
Erkennbar ist hier wieder die hohe CPU-Auslastung: Mit 1.14.4 benutzen alle Server zusammen 1000% von maximal 1200%, das heißt 83% der Maximalauslastung. Der Rest wird für alle anderen Dienste benutzt. Zu sehen ist auch, dass nicht nur ein einzelner Minecraftserver die hohe Last verursacht, sondern alle zusammen. Zum Zeitpunkt des Screenshots hat die Zentralwelt main_c mit 243% von 1200% bzw. mit 20% vom Maximum die meiste Prozessorleistung beansprucht.
Epilog
In diesem Abschnitt möchte ich den technischen Bereich wieder verlassen und beschreiben, warum das Update nicht geklappt hat, wer daran schuld ist und was zukünftig jetzt noch passiert.
Warum hat das Update jetzt nicht geklappt?
Das ist tatsächlich ganz einfach zu beantworten: Die Minecraftserver benötigen mit Version 1.14.4 so viel Leistung, dass im aktuellen Entwicklungsstand unsere Infrastruktur nicht dafür ausreicht. Sie benötigen ein Vielfaches mehr an Rechenleistung als mit 1.13.2 und laufen auch im Vanilla-Teil (den wir nicht optimieren können) schlechter als vorher. Die Server sind mit den geladenen Weltteilen und Tieren mit nur ganz wenigen Spielern schon völlig ausgelastet. Natürlich kann man einen solchen Zustand weder Spielern noch der Hardware zumuten. Da auch unsere kurzfristigen Notfall-Anpassungen am Nachmittag des Updates nicht den gewünschten Erfolg gebracht haben, entschlossen wir uns, das 1.13.2-Backup wieder einzuspielen. Umsonst war das alles natürlich nicht: Wir konnten viele Erkenntnisse und Messdaten sammeln.
Was macht Mojang?
Mit jedem Minecraft-Update wird die Serversoftware deutlich schlechter. "Optimierungen" haben lächerlich schlechte Auswirkungen auf den Server. Neue Features werden so schlampig implementiert, dass auch diese unverhältnismäßig viel Rechenzeit benötigen. Und statt die Fehler in der aktuellen Version zu beheben, wird man auf die nächste Version vertröstet - in der dann auch wieder Features implementiert werden, die so viel Leistung fressen, dass jedes Update für alle Serverbetreiber zur Tortur wird. Wenn es die klugen, unermüdlichen Köpfe in den Entwicklercommunities oder bei großen, kommerziellen Projekten nicht geben würde, die die Software mit Modifikationen verbessert (oder Teile einfach komplett neu schreibt), würde es keine Multiplayerserver geben, auf denen mehr als 10 Leute online sein können. Der Serverquellcode ist nicht öffentlich, was das Arbeiten am Server nochmal deutlich schwerer macht als nötig. Bei Mojang wird scheinbar kaum Zeit für den Multiplayermodus der Java Edition verschwendet, auch wenn ein Großteil der Spielerschaft diesen benutzt.
Natürlich ist an dem gestrigen Problem nicht alleine Mojang schuld. Wir haben die Testergebnisse des Beta-Servers zu optimistisch gesehen, haben eine zu strikt geplante Roadmap für das 1.14.4-Update aufgesetzt, um das Update noch vor dem Geburtstag auf dem Server sehen zu wollen und waren schließlich viel zu überzeugt von unseren Optimierungen, die leider nicht viel daran ändern, dass die Software im Kern nur eines ist: Großer Mist. Es kann doch nicht sein, dass ein Minecraftserver unserer Größe sich ein halbes Rechenzentrum mieten muss.
So gibt es dann nunmal zum Geburtstag diesen Text und kein 1.14.4-Update. Trotzdem werden wir nicht einfach aufgeben ...
Ich möchte an dieser Stelle einen bereits gelöschten Kommentar auf dem Bugtracker von Mojang erwähnen, welcher zeigt, wie traurig auch andere Serverbetreiber über diesen Zustand sind:
Und wie geht es jetzt bei uns weiter?
Wir werden uns jetzt erstmal im (Dev-)Team beraten. Aktuell sind wir schon dabei, die ganzen schönen versionsunabhängigen Erweiterungen, die wir nur in der 1.14-Version unserer Plugins vorgenommen hatten, in die 1.13-Version übertragen zu können (Beispiel: Villager anleinen können). Wir hatten noch weitere tolle Sachen mit der 1.14 geplant und bereits vorbereitet - Die wird es nun demnächst mit der 1.13.2 geben.
Parallel werden wir natürlich weiter an Optimierungen für die 1.14 arbeiten. Wir werden uns in der Entwicklercommunity mit anderen Entwicklern austauschen, weitere Tests machen und die zukünftige Entwicklung ganz genau beobachten. Und vielleicht - ganz vielleicht - gibt es mit der 1.15 ja mal ein Update, was echte Optimierungen an der Serversoftware macht, sodass diese endlich mal direkt nach der Veröffentlichung besser läuft.
Weiterhin werden wir unsere Infrastrukur weiter optimieren und einen Ausbau prüfen. Denn für die Verteilung von Unlimitedworld auf mehrere Maschinen ist fast alles vorbereitet. Solche Schritte werden wir dann aber auch im Dev-Blog dokumentieren.
Für alle, die sich sehr auf das 1.14.4-Update gefreut haben oder die ihren gestrigen Baufortschritt durch das Backup verloren haben, kann ich leider nur eines tun: Um Entschuldigung bitten. Wir lassen uns von diesem Rückschlag nicht unterkriegen! Die Entwicklung von Unlimitedworld wird weiter gehen - und ihr werdet hoffentlich mit dabei sein.
Dieser Text wird natürlich wieder einige Fachbegriffe verwenden und ein wenig tiefer in die Technik hinter dem Server gehen. Ich versuche aber trotzdem alles so darzustellen, dass jeder es verstehen kann. Für die Profis: Einige Dinge sind selbstverständlich vereinfacht. Falls es Fragen gibt, könnt ihr diese gerne unter dem Thema stellen.
Prolog
Wie in dem Dev-Blog-Beitrag "Hinter den Kulissen Teil 1: Minecraftserver" von @RiotSeb beschrieben, ist Unlimitedworld nicht nur ein einzelner Minecraftserver, sondern besteht aus mehreren, die in einem Netzwerk zusammengefasst sind. Konkret sprechen wir hier über insgesamt sechs Minecraftserver auf denen alleine die Hauptwelt läuft, plus diverse Server für die Farmwelt, die Creative-Welt und die Minigame-Welt. Zu Hochzeiten nutzen wir so bis zu zwölf Minecraftserver parallel. Technisch bedingt kann leider nur eine begrenzte Anzahl von Spielern gleichzeitig auf einem Server sein. Durch unser Netzwerk werden die Spieler auf viele Server verteilt, so dass bei 200 Online-Spielern trotzdem auf jedem einzelnen Server nur ca. 30 bis 50 Spieler sind.
Früher war es so, dass man vereinfacht sagen konnte, dass ein Minecraftserver alle seine Weltberechnungen auf einem einzigen Kern des Prozessors (CPU, Central Processing Unit) durchgeführt hat. Unsere Hardware hatten wir so ausgewählt, dass sie genau dem gerecht wird. Wir nutzen einen Hardware-Server (im weiteren Verlauf als Maschine bezeichnet) mit einem Intel Xeon E5-1650 v4 @ 3.60GHz mit 6 Kernen und 12 Threads (parallele Abarbeitungsmöglichkeiten), 128GB DDR4 Arbeitsspeicher und zwei 1,8TB NVMe-SSDs im RAID1. Auf dieser Maschine laufen natürlich auch das Forum, der Teamspeak, unsere Datenbankserver, unsere Entwicklungsinfrastruktur und einige Hintergrunddienste für die Steuerung und das Monitoring des ganzen Systems.
Durch dieses Hardwarekonzept konnten sich die Minecraft- und sonstigen Server problemlos auf die 12 CPU-Threads verteilen. Das hat bis zur Version 1.12 wunderbar funktioniert.
1. Akt: Die Veränderung
Bis zu diesem Punkt hat ein Minecraftserver vor allem von der Single-Core-Performance profitiert: Eine CPU, die einzelne Kerne (Single Core) sehr hoch getaktet hat, sorgte dafür, dass man dort einen Server mit vielen Spielern flüssig laufen lassen konnte. Ich erinnere mich noch an die Zeit mit der Version 1.10, wo es kein Problem war, 120 Leute auf einem einzelnen Server laggfrei spielen zu lassen.
1. Auftritt: Neue Technik
Jedoch entwickeln sich moderne CPUs eher so, dass sie statt wenigen Kernen mit großer Leistung eher viele Kerne mit weniger Leistung haben. Auch Mojang hat dies gemerkt und ab der 1.12 verstärkt damit angefangen, die Prozesse des Servers zu parallelisieren, sodass ein Server die Leistung von mehreren Kernen nutzen kann. Der Hauptprozess des Servers, der für die Berechnung der Welt, der Tiere usw. zuständig ist, bleibt jedoch weiterhin auf einem Kern. Zuletzt wurde so die Lichtberechnung vom Hauptprozess des Servers in einen Nebenprozess ausgelagert. Das klingt alles super, jedoch ist die Umsetzung einfach unglaublich schlecht. Und mit neuen Minecraft-Versionen kommen immer mehr neue, rechenintensive Inhalte dazu, sodass auch die eigentlichen Aufgaben des Hauptprozesses schon zuviel werden. Hinzu kommt, dass die Parallelisierung so schlecht implementiert ist, dass sie mehr Rechenleistung kostet, als es am Hauptprozess sparen könnte. Natürlich benötigen neue Inhalte im Spiel mehr Rechenleistung, jedoch sorgen die "Optimierungen" seitens Mojang dafür, dass mit jeder Version deutlich mehr zusätzliche Rechenleistung benötigt wird als erträglich ist. Zuletzt konnten man an einem nicht optimierten 1.14-Server erkennen, dass dieser bis zu 50% mehr Prozessorleistung und etwa 30% mehr Arbeitsspeicher benötigte als ein 1.13-Server. Wenn man sich überlegt, wie wenig eigentlich dazu gekommen ist, ist das schon heftig. (In diesem Absatz habe ich absichtlich die parallel laufenden Prozess-Threads als Haupt- und Nebenprozesse bezeichnet, der Terminus stimmt natürlich nicht, macht es aber übersichtlicher.)
2. Auftritt: Unsere Anpassungen
Nachdem wir mit den Anpassungen an unseren Plugins für das 1.14-Update recht schnell fertig waren, legten wir das Augenmerk auf die Optimierung der Minecraftserver. Zuerst hofften wir noch, dass Mojang noch Fixes für die 1.14 bringt, jedoch kündigte Mojang mit dem Release der 1.14.4 an, dass man sich dort jetzt auf die 1.15 konzentrieren wolle und man keine weiteren Performanceupdates für die 1.14 herausbringen würde. Ein Schlag für uns, denn nun waren wir wieder auf uns alleine gestellt. Die Entwicklercommunities hinter der von uns eingesetzten Serversoftware Spigot und Paper haben viele Verbesserungen hervorgebracht, welche wir mit eigenen Optimierungen erweitert haben. Zuletzt waren wir mit unseren Tests so zufrieden, dass wir das Update auf 1.14.4 wagten.
Und genau an diesem Punkt möchte ich einmal auf unsere Beobachtungen eingehen und zeigen, wo die Probleme bestehen.
2. Akt: Der Minecraftserver
In diesem Thema schauen wir uns exemplarisch einen unserer Minecraftserver an, konkret die Zentralwelt ohne Spawn. Dieser Server ist besonders interessant, da er als größter und ältester Teil der Welt immer am stärksten belastet ist. Die folgenden Graphen zeigen als rote Kurve immer die Spielerzahl auf dem Server "Zentralwelt". Die Daten stammen von kurz nach 17:00 Uhr vom Tag des Updates und zeigen die vergangenen 24 Stunden. In der ganzen Zeit sind stets weniger als 30 Spieler in diesem Teil der Welt.
1. Aufritt: Ticks per Second
Mincraft ist ein Tick-gesteuertes Spiel. Alle 50 Millisekunden (ms) wird ein Tick ausgelöst, also 20 Ticks pro Sekunde (TPS). Auch wenn niemand etwas macht, bewegen sich mit jedem Tick die Tiere, wachsen die Pflanzen etc.. Normalerweise kann der Server alle Aufgaben, die er in einem Tick erledigen soll, in den zur Vefügung stehenden 50 ms abarbeiten. Dann läuft er mit dem Idealwert von 20 TPS. Im Normalfall wird der Server mit einem Tick sogar schon nach maximal 40 ms fertig und hat dann 10 ms Pause. Es kann aber auch vorkommen, dass bspw. durch die Berechnung von sehr vielen Tieren der Server manchmal mehr als 50 ms für einen Tick braucht. Der Server kann nicht einfach den Tick abbrechen, aber er kann sich mehr Zeit für den Tick nehmen. Das senkt dann die TPS, d.h. es erfolgen weniger als 20 Ticks pro Sekunde. Hier ist einmal dargestellt, was eine Veränderungen der TPS für das Spielerlebnis auf dem Server bedeutet:
18 - 20 TPS: Der Server läuft gut, Schwankungen kommen ab und an vor, stören aber selten.
15 - 18 TPS: Der Server läuft noch annehmbar, jedoch hängen Tiere und Spieler schon merkbar und Interaktionen finden verspätet statt.
10 - 15 TPS: Der Server läuft schlecht, man muss fast alle Blöcke mehrmals abbauen, der Tagesrhythmus springt.
0 - 10 TPS: Das Spielen auf dem Server ist kaum noch möglich, man wird ständig zurückgesetzt und der Server kann jederzeit abstürzen.
Zusammengefasst sollte also jeder Server mit 18 bis 20 TPS laufen. Jetzt schauen wir uns mal an, wie das mit dem Update aussah (grüne Kurve und linke Skala = TPS, rote Kurve und rechte Skala = Spieler in der Zentralwelt):
Nach dem Update ist aber plötzlich alles anders: Die TPS fallen mit vergleichbarer Spielerzahl schlagartig unter sieben - zeitweise hatten wir nur 2,48 TPS! Dieser Zustand ist keinesfalls hinnehmbar. Im Graphen erkennt man ganz gut den Restart gegen 14:30 Uhr sowie eine Verbesserung der TPS, als nur noch 10 Spieler auf dem Server waren. (Funfact: Wir überwachen laufend die TPS aller Server und hatten die Graphen so eingestellt, dass die TPS nur zwischen 14 und 22 angezeigt werden, weil sie nie darunter fielen. Daher konnten wir die schlechten Werte anfangs gar nicht sehen und mussten die Graphen nach unten erweitern.)
Woran hat diese rapide Verschlechterung nun gelegen? Üblicherweise können wir die Ursache an den Timings (quasi einer Aufgabenübersicht des Servers) ablesen, doch das war diesmal nicht möglich, da die Auslastung der Maschine über die ganze Zeit kritisch hoch war (siehe 3. Akt). Erkennbar war nur eine sehr hohe Auslastung durch Entities, also vor allem Tiere, besonders auch durch Villager, die seit der 1.14 nicht mehr nur zwei internen Bewegungszielen nachgehen (z.B. Haustür oder Feld aufsuchen) sondern, trotz Optimierungen, über zehn (u.a. Arbeitsblock, Bett und Glocke aufsuchen). Weiterhin kann man sagen, dass die 1.14.4 einfach katastrophal läuft. Viele Informationen deuten darauf hin, dass die Minecraftserver für einige Sachen viel mehr Leistung benötigen als eigentlich nötig wäre. Neben den Änderungen an der Lichtberechnung verursachen scheinbar vor allem auch "Optimierungen" seitens Mojang beim Laden und Entladen von Chunks eine untolerierbare Mehrbelastung.
2. Auftritt: Arbeitsspeicher
Um Welten, Spieler, Tiere usw. im Prozess schnell zugreifbar zu machen, benötigt ein Minecraftserver - wie jede andere Anwendung auch - Arbeitsspeicher (RAM). Ein typischer Irrglaube ist, dass Minecraftserver dabei besonders viel RAM benötigen. Unsere Minecraftserver benötigen üblicherweise nur maximal 4 GB RAM, wobei davon etwa 1 GB von den Daten unserer eigenen Plugins belegt wird.
Mit der 1.14.4 war uns schon bekannt, dass deutlich mehr Chunks geladen bleiben als bisher und jeder Minecraftserver so etwa 30 % mehr RAM benötigen wird. Dies haben wir während des Updates passend eingerichtet. Freie Ressourcen hatten wir glücklicherweise genug. So sah die Veränderung dann im Betrieb aus (violette Kurve und linke Skala = RAM, rote Kurve und rechte Skala = Spieler in der Zentralwelt).
Die violette Kurve zeigt, dass die Belegung des RAMs schwankt. Dies ist ganz normal: Daten, die beim Prozess nicht mehr benötigt werden, wie z.B. ein Chunk, der nicht mehr geladen ist und bereits auf die Festplatte gesichert wurde, werden nicht sofort, sondern später zeitversetzt vom sogenannten GarbageCollector (Müllsammler) freigeräumt. Im normalen Serverbetrieb funktioniert der GarbageCollector so, dass er entweder die freie Zeit zwischen zwei Ticks nutzt, um unbenutzte Daten wegzuräumen oder dass er so weit wie möglich entkoppelt vom Serverprozess funktioniert, um diesen nicht zu stören.
Da aber nach dem Update auf die 1.14.4 zwischen den Ticks keine Zeit mehr übrig blieb und die Auslastung der Maschine auch teilweise zu hoch war, damit der GarbageCollector seine Aufgabe entkoppelt durchführen konnte, kann man an zwei Stellen erkennen, wie der RAM der Zentralwelt bis zum von uns festgelegten Maximalwert von 6 GB gefüllt wird, da der GarbageCollector überhaupt nicht mehr nicht aktiv wurde und keine Daten mehr wegräumte.
Wenn der Speicher bis zu seinem zugewiesenen Limit komplett vollläuft, wird automatisch eine Notfallaktion, der sogenannte FullGC durchgeführt. Dabei wird der Serverprozess angehalten und alle Leistung für das Freiräumen des RAMs benutzt. Das Resultat ist ein sogenanntes Stop-The-World-Event, weil wirklich alles im Prozess pausiert. Bei einem Minecraftserver kann das dazu führen, dass es kurz massiv laggt oder es sogar zu einem Timeout bei den verbundenen Spielern kommt und sie die Verbindung zum Server verlieren. Deshalb arbeiten wir daran, diese FullGCs mit diversen Optimierungen zu verhindern - bei der 1.14 hat das leider nicht geklappt.
3. Auftritt: Weitere Überwachungsparameter
Natürlich überwachen wir noch einen Haufen weitere Parameter für jeden Server. Ich habe hier noch zwei Graphen, die sehr interessant sind.
Zuerst mal ein gutes Zeichen. Hier ein Graph, bei dem die geladenen Entities in orange (Tiere, Monster, Bilderrahmen, Rüstungsständer usw.) und Tiles in gelb (Blockinhalte wie Kisten, Öfen, Trichter usw.) zeigt (gemeinsame Skala links). Die rote Kurve und die rechte Skala zeigt wieder die Anzahl der Spieler in der Zentralwelt.
Hier kann man erkennen, dass es vor und nach dem Update kaum Veränderungen gab. Das ist genau so wie erwartet: Die Anzahl der geladenen Tiere und Blockinhalte hat sich durch das Update nicht verändert.
Weiterhin zeichnen wir auf, wie viele Chunks auf jedem Server geladen sind (gelbe Kurve mit Skala links). Hier erkennt man alleine für die Zentralwelt schon einen großen Unterschied zwischen vor und nach dem Update:
Beim Laden der Chunks haben wir bereits diverse Optimierungen am Server vorgenommen. Jedoch bleibt das weiterhin ein guter Ansatzpunkt: Kann man vielleicht die Zahl der passiven Chunks reduzieren? Gibt es hier noch Fehler, welche den Lastanstieg begründen? Oder haben wir einen Fehler in unseren Optimierungen gemacht? Hier werden wir versuchen, den Server weiter zu optimieren.
3. Akt: Die Maschine
1. Auftritt: Prozessorleistung
Oben habe ich ja schon beschrieben, dass es auch ein Problem mit der Auslastung der Maschine, also mit der Hardware gab. Zu Beginn des Updates auf die Version 1.14.4 haben wir alle unsere Entwicklungsserver heruntergefahren (der Beta-Server und interne Welten, auf den wir Sachen vorbauen und testen). Ebenfalls haben wir Unlimitedworld mit der 1.14.4 mit minimalem Unfang gestartet - also nur mit Farmwelt und Creative-Welt ohne Minigame-Welt - um ein ungetrübtes Bild von den Leistungsanforderungen der 1.14 für den reinen Spielbetrieb zu bekommen und um ihm die maximalen Ressourcen zu geben. Nachdem wir die Tests auf dem Beta-Server umgerechnet hatten, kamen wir zu dem Entschluss, dass wir mit den bestehenden Ressourcen genau auskommen müssten - Pustekuchen:
Am Tag vor dem Update (Wed = Mittwoch) erkennt man, dass die Leistung der Maschine ausreichend ist. Die Belastungsgrenze wird kurz vor 22:00 Uhr mit 1100 % erreicht. Zu diesem Zeitpunkt waren 150 Spieler online und neben den Spielwelten liefen auch noch alle internen Server.
Im weiteren Verlauf erkennt man das tägliche Backup um 4:00 Uhr als kleine Last-Spitze, dann das Ansteigen der Last durch mehr Spieler am Vormittag des Donnerstags (Thu) sowie die Lastspitze durch das Backup um etwa 12:00 Uhr. Während wir das Update durchgeführt haben, haben wir auch alle Welten für die 1.14 konvertiert, damit dies nicht im Serverbetrieb geschehen muss, was eine weitere Spitze verursacht.
Um kurz vor 14:00 Uhr öffneten wir den Server dann wieder - und innerhalb weniger Minuten stieg die Serverlast massiv an. Zwar ist immer noch ein kleiner gelber Freizeit-Bereich zu sehen, aber das täuscht. Die Messwerte werden über 5 Minuten gemittelt und aus verschiedenen technischen Gründen (bspw. auch Hyperthreading vs. Turbo-Takt) können diese bei unserer Art der Belastung nicht über den Wert steigen, den man oben erkennt. Der Prozessor war also komplett ausgelastet, es war keine Rechenzeit mehr dafür frei, die Ticks gescheit zu berechnen und andere wichtige Berechnungen noch korrekt durchzuführen. Das wäre für eine kurze Zeit auszuhalten, aber dauerhaft verursacht eine solche hohe Auslastung noch andere Probleme. Irgendwann muss man sogar damit rechnen, dass die Lebenszeit der Hardware drastisch reduziert wird.
Unsere Hochrechnungen aus den Beta-Tests waren also nicht korrekt gewesen. Stattdessen benötigt die 1.14.4 mit unserem Entwicklungsstand, also trotz der zahlreichen Optimierungen, immer noch unglaublich viel Prozessorleistung. Für einen normalen Betrieb mit 120 Spielern würden wir in diesem Zustand etwa das Doppelte an Prozessorleistung benötigen, als noch mit der 1.13.2.
2. Auftritt: Arbeitsspeicher
Nun möchte ich noch einmal auf die Thematik mit dem Arbeitsspeicher eingehen, bei der wir glücklicherweise nicht so kalt überrascht wurden:
Vergleicht man den grünen Bereich vor und nach dem Update, fällt auf, dass die wenigen Server, die in der Minimalversion von Unlimitedworld mit der 1.14.4 laufen, genauso viel RAM brauchen, wie die vielen Server mit 1.13.2. Damit hatten wir gerechnet und die Ressourcen hatten dafür gereicht. Zusätzlich erkennt man, dass das Betriebssystem deutlich aggressiver mit dem Cachen beginnt. Der Cache füllt sich nicht langsam über den ganzen Tag, sondern sofort. (Dies sorgt im übrigen auch dafür, dass in orange ein spezieller Cache, der Slab-Cache, stärker beansprucht wird als vorher). Durch die erheblich größere Menge an Lade- und Entladevorgängen bei den Chunks (siehe oben) hat das Betriebssystem viel schneller begonnen, Daten zu cachen - das hat es so gut gemacht, dass tatsächlich durch die 1.14.4 kein Anstieg der Festplattenbelastung (hier nicht dargestellt) zu erkennen war. Hier kann man also wenigstens von einem kleinen Erfolg sprechen: Arbeitsspeicher und Festplatte haben sich optimal verhalten - genau so, wie geplant.
Hier nochmal eine zusammenfassende Grafik aus dem Tool netdata, in dem wir mit einer eigenen Erweiterung die Auslastungen, die nur von den Minecraftservern kommen, präziser bestimmen können. In diesem Beispiel ein 10-Minuten-Ausschnitt ab 17:00 Uhr am Tag des Updates. Die Grafik zeigt die CPU-Auslastung durch die verschiedenen Minecraftserver, die rechts farblich aufgelistet sind (die Zentralwelt heißt "main_c").
Epilog
In diesem Abschnitt möchte ich den technischen Bereich wieder verlassen und beschreiben, warum das Update nicht geklappt hat, wer daran schuld ist und was zukünftig jetzt noch passiert.
Warum hat das Update jetzt nicht geklappt?
Das ist tatsächlich ganz einfach zu beantworten: Die Minecraftserver benötigen mit Version 1.14.4 so viel Leistung, dass im aktuellen Entwicklungsstand unsere Infrastruktur nicht dafür ausreicht. Sie benötigen ein Vielfaches mehr an Rechenleistung als mit 1.13.2 und laufen auch im Vanilla-Teil (den wir nicht optimieren können) schlechter als vorher. Die Server sind mit den geladenen Weltteilen und Tieren mit nur ganz wenigen Spielern schon völlig ausgelastet. Natürlich kann man einen solchen Zustand weder Spielern noch der Hardware zumuten. Da auch unsere kurzfristigen Notfall-Anpassungen am Nachmittag des Updates nicht den gewünschten Erfolg gebracht haben, entschlossen wir uns, das 1.13.2-Backup wieder einzuspielen. Umsonst war das alles natürlich nicht: Wir konnten viele Erkenntnisse und Messdaten sammeln.
Was macht Mojang?
Mit jedem Minecraft-Update wird die Serversoftware deutlich schlechter. "Optimierungen" haben lächerlich schlechte Auswirkungen auf den Server. Neue Features werden so schlampig implementiert, dass auch diese unverhältnismäßig viel Rechenzeit benötigen. Und statt die Fehler in der aktuellen Version zu beheben, wird man auf die nächste Version vertröstet - in der dann auch wieder Features implementiert werden, die so viel Leistung fressen, dass jedes Update für alle Serverbetreiber zur Tortur wird. Wenn es die klugen, unermüdlichen Köpfe in den Entwicklercommunities oder bei großen, kommerziellen Projekten nicht geben würde, die die Software mit Modifikationen verbessert (oder Teile einfach komplett neu schreibt), würde es keine Multiplayerserver geben, auf denen mehr als 10 Leute online sein können. Der Serverquellcode ist nicht öffentlich, was das Arbeiten am Server nochmal deutlich schwerer macht als nötig. Bei Mojang wird scheinbar kaum Zeit für den Multiplayermodus der Java Edition verschwendet, auch wenn ein Großteil der Spielerschaft diesen benutzt.
Natürlich ist an dem gestrigen Problem nicht alleine Mojang schuld. Wir haben die Testergebnisse des Beta-Servers zu optimistisch gesehen, haben eine zu strikt geplante Roadmap für das 1.14.4-Update aufgesetzt, um das Update noch vor dem Geburtstag auf dem Server sehen zu wollen und waren schließlich viel zu überzeugt von unseren Optimierungen, die leider nicht viel daran ändern, dass die Software im Kern nur eines ist: Großer Mist. Es kann doch nicht sein, dass ein Minecraftserver unserer Größe sich ein halbes Rechenzentrum mieten muss.
So gibt es dann nunmal zum Geburtstag diesen Text und kein 1.14.4-Update. Trotzdem werden wir nicht einfach aufgeben ...
Ich möchte an dieser Stelle einen bereits gelöschten Kommentar auf dem Bugtracker von Mojang erwähnen, welcher zeigt, wie traurig auch andere Serverbetreiber über diesen Zustand sind:
Und wie geht es jetzt bei uns weiter?
Wir werden uns jetzt erstmal im (Dev-)Team beraten. Aktuell sind wir schon dabei, die ganzen schönen versionsunabhängigen Erweiterungen, die wir nur in der 1.14-Version unserer Plugins vorgenommen hatten, in die 1.13-Version übertragen zu können (Beispiel: Villager anleinen können). Wir hatten noch weitere tolle Sachen mit der 1.14 geplant und bereits vorbereitet - Die wird es nun demnächst mit der 1.13.2 geben.
Parallel werden wir natürlich weiter an Optimierungen für die 1.14 arbeiten. Wir werden uns in der Entwicklercommunity mit anderen Entwicklern austauschen, weitere Tests machen und die zukünftige Entwicklung ganz genau beobachten. Und vielleicht - ganz vielleicht - gibt es mit der 1.15 ja mal ein Update, was echte Optimierungen an der Serversoftware macht, sodass diese endlich mal direkt nach der Veröffentlichung besser läuft.
Weiterhin werden wir unsere Infrastrukur weiter optimieren und einen Ausbau prüfen. Denn für die Verteilung von Unlimitedworld auf mehrere Maschinen ist fast alles vorbereitet. Solche Schritte werden wir dann aber auch im Dev-Blog dokumentieren.
Für alle, die sich sehr auf das 1.14.4-Update gefreut haben oder die ihren gestrigen Baufortschritt durch das Backup verloren haben, kann ich leider nur eines tun: Um Entschuldigung bitten. Wir lassen uns von diesem Rückschlag nicht unterkriegen! Die Entwicklung von Unlimitedworld wird weiter gehen - und ihr werdet hoffentlich mit dabei sein.
), für diesen sehr detaillierten Einblick in das, was in den letzten Stunden und Tagen passiert ist. Während man sich's als nicht ganz so amateurhaften Laien grob vorstellen konnte, so ist das hier doch ne Hausnummer. Super erklärt, und die Entschuldigung am Ende brauchts auch nicht. Ihr habt euer Möglichstes getan!
