1. Hallo Gast, Minecraft ist ein Spiel und das soll es auch bleiben. Um Minecraft spielen zu können ist es nicht nötig anderen Spielern deinen echten Namen, deinen Wohnort oder dein Alter zu verraten. Fast alle Minecraftspieler sind Leute wie du die einfach nur bisschen Zeit in Minecraft verbingen wollen um Spaß zu haben. Es gibt jedoch auch ein paar wenige, die gezielt versuchen dich nach diesen Informationen zu befragen in der Hoffnung dass du ihnen antwortest. Gib diesen Personen keine Möglichkeit dir gefährlich zu werden in dem du dich an die einfache Regel hältst deinen Wohnort weder öffentlich noch in privaten Nachrichten oder Skype zu nennen und auch persönlichen Treffen nicht zustimmst! Sollte dich dennoch jemand hartnäckig danach fragen, informiere uns über unser Kontaktformular.

[Biete] Java GC-Log-Analyse und individuelle GC-Optimierung

Dieses Thema im Forum "Biete Dienstleistungen" wurde erstellt von c-eAgle, 11. Februar 2014.

  1. c-eAgle
    Offline

    c-eAgle

    Registriert seit:
    14. Juli 2011
    Beiträge:
    38
    Minecraft:
    ceagle2
    Hallo,

    da heutzutage immer mehr Minecraft-Serverbetreiber auf keine konkreten, GC-bezogenen Java-Startparameter mehr zurückgreifen (GC = Garbage Collector), sondern Java diese Entscheidung für sie treffen lassen, muss zunächst einmal gesagt werden, dass die Entscheidung, welche Java dabei auf Basis extrem weniger Kriterien trifft, für Minecraft-Server fast grundsätzlich suboptimal ist - das primäre Problem ist dabei, dass der von Java ausgewählte Garbage-Collector bei jedem Durchlauf sogenannte StopTheWorld-Events beinhaltet. Sofern diese eine gewisse Dauer überschreiten, empfinden Spieler dies zunehmend als Lag bzw. Standbild seitens des Servers. Soweit nicht unnormal für die meisten Minecraft-Spieler, jedoch benötigt man dabei ein paar Hintergrundinformationen, um zu verstehen, an welcher Stelle StopTheWorld genau schlecht ist und wie die verfügbare Alternative konzeptionell aussieht.

    Je nachdem, welcher Garbage-Collector verwendet wird, wird der zugewiesene Heap (= nutzbarer Teil des Arbeitsspeichers) in bestimmter Weise aufgeteilt. Der von Java selbst ausgewählte GC verwendet in erster Linie zwei Generationen - jung und alt - und trennt diese strikt. Entsprechend gibt es zwei Stufen an Garbage-Collections, welche sich jeweils auf eine der Generationen konzentrieren und für diese optimiert sind. Die Collections der jungen Generation nutzen in soweit jedem verfügbaren Collector ein StopTheWorld-Event, welches potentiell länger andauert, je größer die junge Generation ist - dort haben wir das erste Problem, für welches Parameter zur Optimierung existieren und genutzt werden sollten. Das eigentliche Problem sind jedoch die Collections der alten Generation. Überlässt man Java die Wahl des Garbage-Collectors, so werden diese alten Collections mit mehr zugewiesenem RAM in jedem Fall ein immer deutlicher spürbares StopTheWorld-Event beinhalten - oft wird der Irrglaube ausgesprochen, mehr RAM verringere serverseitige Lags. Das Gegenteil ist der Fall, wenn man Java die Wahl des GC überlässt.

    Die grundsätzliche Alternative sieht dabei derart aus, dass die Collections der alten Generation (großteils) in Form von Concurrent-Events stattfinden können - diese halten den eigentlichen Minecraft-Server nicht wie StopTheWorld-Events an, sondern laufen neben diesem her und verrichten ihre Arbeit nebenbei. Mit Java7 bzw. Java8 hat man dabei die Wahl zwischen zwei möglichen Collectors: CMS (ConcMarkSweep) und G1 (GarbageFirst). Diese würde Java bisher nie von sich aus wählen - daher ist dies bereits der erste Schritt hinsichtlich einer GC-Optimierung.

    CMS und G1 haben unterschiedliche Pros und Contras, so dass man, wenn man diese bedenkt, nur individuell entscheiden kann, welcher sich für wen am besten eignet. Sie bringen unterschiedliche weitere Parameter mit, welche es erlauben, den jeweiligen Collector weiter an die eigenen Bedürfnisse anzupassen - die java-seitigen Standardwerte dieser Parameter sind für Minecraft großteils suboptimal, was in erster Linie daran liegt, dass kein pauschales Rezept für alle Server am besten ist, sondern individuelle Optimierung stets zu besseren Ergebnissen führt.

    Behaupte ich das nun nur im Sinne eines weiteren (Irr-)Glaubens? Nein, denn die optimierten Unterschiede lassen sich in jedem Fall objektiv belegen - dazu gibt es die Möglichkeit, Logs durch den verwendeten Garbage-Collector anfertigen zu lassen. Das Anfertigen der Logs wäre in dem Sinne der erste Schritt von DIR, wenn du mit GC-Aktivität eher wenig anzufangen weißt und mit Analysen und ggf. Optimierungen beginnen möchtest. Füge dazu zunächst folgende Parameter mit in die Startparameter deines Minecraft-Servers ein:

    -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy -XX:+PrintPromotionFailure

    Der erste dieser Parameter sorgt dafür, dass im Serverordner eine Datei namens gc.log angelegt wird, welche mit jedem Neustart des Minecraft-Servers komplett neu erzeugt wird. Es gibt diverse Einzelheiten, welche man durch derartige Parameter in den GC-Logs individuell ein- und ausblenden kann. Wird etwa zum G1GC verwendet, empfehle ich, -XX:+PrintGCDetails wegzulassen.

    Wenn dir nun in den nächsten Tagen GC-Logs vorliegen, kannst du in erster Linie schauen, wieviel Zeit die einzelnen Collects in Anspruch nehmen - die meisten Collects handeln dabei von der jungen Generation und sollten in der Regel sehr kurz sein. Um serverseitige Standbilder zu vermeiden, muss beachtet werden, dass Minecraft einen Tick alle 50ms berechnen möchte, wofür jeweils Rechenzeit nötig ist. Sprich: alle 50ms hat man einen gewissen Zeitpuffer, welchen ich hier willkürlich mit rund 10-30ms festlege, welcher prinzipiell für GC-Aktivität genutzt werden kann, wenn auch nicht muss. Alles darüberhinaus würde für Spieler potentiell spürbar sein und IST durch Optimierung praktisch vollständig vermeidbar.

    Mein grundsätzliches Angebot: ich biete konstante GC-Analyse sowie Feedback im Sinne von Änderungen an den GC-bezogenen Startparametern an, um die Verarbeitung der einzelnen Generationen Schritt für Schritt weiter zu verbessern. Dieser Prozess nimmt, bis man ein Optimum erreicht hat, manchmal nur Tage, in den meisten Fällen ein paar Wochen in Anspruch - nicht in Form durchgehender Arbeit, sondern in Form höchstens einer täglichen Analyse, nachdem der Server jeweils solange wie möglich ohne Neustart aktiv war. Je nachdem, an welcher Stelle Collects zu lange StopTheWorld-Events nach sich ziehen können, lässt sich das Verhalten des Garbage-Collectors entsprechend anpassen, um diese auf unterschiedlichste Weisen präventiv zu verhindern.

    Die konkrete GC-Analyse kann dabei wie folgt ablaufen: du richtest einen FTP-Zugang ein, in welchen du via Cronjob das gc.log aus deinem Serverordner sowie die aktuell verwendeten Startparameter (soweit diese keine kritischen Informationen enthalten) alle 15-60 Minuten hineinkopieren lässt - die Zugangsdaten für diesen FTP-Zugang lässt du mir zusammen mit deinen konkreten Serverspezifikationen (bzgl. CPU, RAM, HDD) einfach zukommen. Ich schaue das Log stichprobenartig an, soweit der Minecraft-Server zu dem Zeitpunkt bereits lange genug am Stück lief, und werte das Log auf dieser Basis aus, um anschließend bei Bedarf Optimierungsvorschläge auf Basis der vorhandenen Hardwareressourcen zu unterbreiten und deren konkrete Auswirkungen (direkte sowie indirekte) ausführlich zu schildern. Wahlweise per E-Mail oder hier per PN.

    Warum biete ich das überhaupt an? Ist schließlich meine Zeit, und ich verlange nichts im Gegenzug - wobei ich freiwilliger Dankbarkeit gegenüber natürlich nicht abgeneigt bin. Hängt jedoch vor allem damit zusammen, dass heutzutage kaum noch jemand derartige Optimierungen nutzt, da die meisten Minecraft-Serverbetreiber sich kaum oder gar nicht mit der Materie befassen, insofern mit entsprechenden Parametern ggf. eher das Gegenteil erreichen würden (quasi suboptimale Verschlimmbesserungen) und insofern das Spielgefühl der Spieler nur weiter beeinträchtigen würden. Das kleinere Übel, einfach nichts zu tun, wird da natürlich bevorzugt. So oder so ist dabei der Ruf entstanden, dass Minecraft-Server selbst ganz ohne Plugins und mit bester Hardware grundsätzlich von Lags betroffen seien - was fundamentaler Unsinn ist. Die im Regelfall feststellbaren, GC-basierten Verzögerungen lassen sich mit individueller Optimierung praktisch restlos unter Kontrolle bringen, was, wie gesagt, in den meisten Fällen ein Prozess von mehreren Wochen (mit ca. einer Stunde Gesamtaufwand alle paar Tage) ist.

    Ich selbst bin seit 2002 primär als Domain-Provider mit Hochverfügbarkeits-Nameservern für Privat- und Firmenkunden selbständig, befasse mich nunmehr seit 2011 ausführlich mit GC-Analyse und -Optimierung und helfe zu diesem Zeitpunkt bereits bei mehreren Minecraft-Servern hinsichtlich GC-Optimierung. Hat man die konkreten Mechaniken, welche im Hintergrund bei den GCs verwendet werden, erst einmal verinnerlicht, wird die Optimierung intuitiv relativ einfach - doch verstehe ich absolut, dass nicht jeder die Zeit oder Motivation findet, sich mit dieser Materie zu befassen. Fundierte Schilderungen zu Auswirkungen bzgl. von mir vorgeschlagener Optimierungen gibt es dennoch, soweit nicht explizit das Gegenteil gewünscht wird.

    Bei Fragen stehe ich jederzeit zur Verfügung - in erster Linie per PN oder hier im Thread, wahlweise per E-Mail oder in Ausnahmefällen via TeamSpeak, soweit die Zeit es zulässt.

    Viele Grüße,
    cea
     
    #1
  2. Baba43
    Offline

    Baba43 Ehem. Teammitglied

    Registriert seit:
    5. November 2012
    Beiträge:
    590
    Das Angebot finde ich wirklich klasse und lobenswert ;)

    Vielleicht wäre es interessant und gewinnbringender für dich, wenn du konkrete Analysen durchführst und hier oder in einem anderen Thread kommentierst. So können interessierte Leute jederzeit ohne dein aktives Zutun etwas lernen, auch wenn du mal keine Zeit oder Lust mehr hast.
     
    #2