Minecraft Server Probleme

    Erstmal zu meinem System:
    Uranus light
    Debian Squeeze 64Bit
    Java: openjdk-6-jre (openjdk-7-jre hat sich nicht installieren lassen)


    der Minecraft server ist derzeit das einzige was auf dem Server Läuft


    hier mal was bei top steht zu minecraft:


    ich starte es mit:
    screen -s minecraft java -Xms450M -Xmx450M -jar minecraft_server.jar nogui
    hatte es auch mit verschiedenen Arbeitsspeicher zuteilungen versucht (zuerst mit 1024M und runter bis 256M) bei 450 bleibt VIRT knapp unter dem 1GB
    und an dem Problem ändert es nix


    ich benutze den standart minecraft server ohne plugins
    ich spiele auf dem server meistens alleine manchmal 2 oder max 3 Leute


    Server.properties:


    Mein Problem ist Folgendes:
    der server "hängt" zwischendurch bis zu 10 secunden
    d.h.:
    - 5 - 10 abgebaute blöcke dropen keine materialien und erscheinen dann wieder und ich werde zurück gesetzt
    - Tiere oder monster bleiben hängen und lassen sich nicht angreifen.
    - andere spieler bleiben hängen und werden erst nach den lag wieder da angezeigt wo sie sind


    manchmal läuft der server ein paar minuten ohne Probleme aber häufig kommt das mehrmals in der minute vor


    ich hab auch schon versucht eine neue welt zu spielen aber da habe ich das selbe Problem
    auch mit bukkit habe ich es versucht aber das läuft eher schlechter als besser


    ich habe auch einmal auf meinem Windows PC den server getestet da läuft er ohne Probleme


    btw
    ich hatte vor ca. einem halben jahr schonmal einen minecraft server laufen der aber ohne probleme funktioniert hat


    vielleicht hat ja jemand eine idee was ich noch versuchen könnte
    all die vorschläge in den anderen threads haben mir nix gebracht

    [quote='AtomAtomic','index.php?page=Thread&postID=45055#post45055']- 5 - 10 abgebaute blöcke dropen keine materialien und erscheinen dann wieder und ich werde zurück gesetzt[/quote]Kein Wunder bei den derzeitigen Startwerten. xms und xmx 450M reicht für einen gerade so nackten Start des Minecraftservers. Ein Spieler und die Schotten sind in Sachen RAM dicht. Bitte den Server mal mit xms 512 und xmx 1512 starten und während dem spielen wo die Probleme auftreten die RES und RSS Werte in top für den Java Prozess beobachten.

    hab es jetzt mit 512 und 1512 gestartet und die Probleme traten nach wenigen secunden direkt erneut auf


    Das selbe
    es hat nichteinmal eine Minute gedauert und ich wurde wieder so 6 blöcke zurück gesetzt


    nachdem er ein paar minuten gelaufen ist sieht es so aus:


    aber das Problem besteht weiter

    Dann ist es definitiv kein Serverproblem ;) Zumindest keins des vServers. Das beschriebene Problem hat als Ursache vorwiegend Chokes was wiederum am Routing / der Anbindung von Client -> Server liegt aber daran kann man vServer seitig nichts ändern.
    Sie werden auch einen guten Ping haben wenn Sie den vServer direkt pingen. Ich empfehle sich mit entsprechender Fachliteratur kundig zu machen bezüglich Chokes, Loss sowie dem beschrieben Problem per Google. Das Problem ist ein allgemeines Minecraftproblem.

    openjdk-6-jre

    Code
    java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

    Des Linux System Debian Squeeze 64Bit setze ich auch ein.
    Ich setze bei meinen Minecraft Server immer die Java Version von Oracle und nicht die Java Version von OpenJDK ein.


    Möglichkeit 1:
    Hatte mit OpenJDK auch Probleme gehabt.
    Das Java von Orcale muss man sich aber Manuell downloden und installieren.
    Ich habe das ganze nach dieser Anleitung gemacht: Installing Java 7 on Debian


    Hinweis: Dort muss man die Pfade anpassen, weil breites Java mit den Update Nr. 4 erschienen ist.


    Möglichkeit 2:
    Vielleicht die Firewall nicht richtig eingestellt z.B ein Limit gesetzt oder etc.


    Ps: Das liegt nicht am Server, weil Netcup hätte schon bemerkt das irend was nicht stimmt.

    Mit freundlichen Grüßen
    Track1991

    ja hatte erst die SUN version drauf gehabt mir wurde aber openjdk vom support empfohlen weshalb ich das drauf hab
    aber kann ja mal das andere installieren


    an der Firewall hab ich garnix geändert

    das war die sun-java6-jre gewesen
    halt die aktuellste die ich über apt-get installieren kann


    naja ich werde dann heute oder morgen wenn ich zeit finde mal versuchen java 7 zu installieren

    habe jetzt Java 7 drauf und es läuft auf alle fälle besser
    (die Probleme treten nicht mehr so häufig auf)
    aber sie sind immernoch vorhanden


    Code
    java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)

    Klingt von den Symptomen her nach FullGCs oder nach übertrieben langen MinorGCs - ich betreibe selbst seit über einem Jahr Bukkit- sowie fCraft-Server, wenn auch auf Rootservern. Du könntest zunächst mal GC-Logs machen, um zu schauen, ob meine Vermutung zutrifft. Trag dafür einfach mal noch folgende Parameter mit ein und poste ein paar Auszüge der Logs mal hier rein:


    -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log


    Das Log wird jeweils neu erzeugt, wenn der MC-Server neu gestartet wird.


    Da du bei deinen Startparametern keinen GC angibst, wird Java bei den Bedingungen vermutlich sowohl für MinorGCs als auch für FullGCs, falls diese nötig werden, den Minecraft-Prozess vollständig anhalten. Dass das bei MinorGCs der Fall ist, lässt sich nicht wirklich verhindern (nur minimieren), aber bei den FullGCs lässt es sich vermeiden. Zunächst würde ich vorschlagen, erstmal den Bedarf an FullGCs zu senken, indem der TrainGC versucht wird - den schlagen sie bei Bukkit auch vor, allerdings ist der nur bei kleinen Servern wirklich sinnvoll. Die einzigen Parameter, die ich dafür empfehlen würde, wären:


    -Xincgc -XX:+DisableExplicitGC


    Wobei letzterer einfach nur dafür sorgt, dass nicht etwa irgendwelche Plugins sinnloserweise für FullGCs sorgen - es gibt Autoren, die das ernsthaft versuchen. Sollte es damit immernoch die genannten Lags geben, könnte man die FullGCs vom CMS durchführen lassen, da der (außer für Compactions) kein Anhalten des Minecraft-Serverprozesses erfordert. Ich habe unsere eigenen Startparameter mal herangezogen und entsprechend für Single-Core-Maschinen angepasst:


    -server -XX:+UseConcMarkSweepGC -XX:-UseParNewGC -Xmx1G -XX:NewSize=384M -XX:MaxNewSize=384M -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=20 -XX:CMSTriggerPermRatio=90 -XX:CMSTriggerRatio=65 -XX:CMSInitiatingOccupancyFraction=65 -XX:CMSMarkStackSize=2M -XX:CMSMarkStackSizeMax=32M -XX:CMSRemarkVerifyVariant=2 -XX:+ExplicitGCInvokesConcurrent -XX:+NeverTenure -XX:SurvivorRatio=8 -XX:MaxGCPauseMillis=500 -XX:MaxGCMinorPauseMillis=100 -XX:CMSAbortablePrecleanWaitMillis=100 -XX:CMSMaxAbortablePrecleanTime=2000 -XX:+CMSClassUnloadingEnabled


    Bei Bedarf kann ich auch gern alles daran ausgiebig erklären. Wir haben rund 4 Monate gebraucht, in denen wir wirklich ALLES sinnvolle ausprobiert haben - also nicht diese amateurhaften Patzer, wo Leute mehrere komplementäre GCs in den gleichen Startparametern eintragen - bis wir schließlich welche hatten, durch die sich die GC-bezogenen Lags wirklich vermeiden lassen. Wir haben, nebenbei erwähnt, auch den GarbageFirst (G1-GC) ausgiebig getestet, aber... nee, die Performance vom CMS holt er leider noch nicht ein, so vielversprechend er auch sein mag.


    Einziges Manko am empfohlenen CMS-GC: man sollte den MC-Serverprozess je nach Spielerzahl regelmäßig (z.B. alle 24-48 Stunden) neu starten, da es bei diesem GC zur Fragmentierung im verwendeten RAM kommt, womit sonst im Laufe der Zeit mehr und mehr Bereiche praktisch nicht mehr für den MC-Server nutzbar sind. Bei -Xmx mit mehreren GB würde sich das zwar weitestgehend selbst erledigen, allerdings hat man selbst dann noch leichte Performance-Einbußen. Die Fragmentierung würde durch einen Neustart vollständig zurückgesetzt werden. Die Alternative wären Collections - das, was der CMS im absoluten Notfall macht. Dabei wird der Serverprozess angehalten und der verwendete RAM wird defragmentiert. Es lässt sich hierbei auch einstellen, ob er dabei einen FullGC und ob er vor dem FullGC noch einen MinorGC durchführen soll. Allerdings wäre das wiederrum ein Riesen-Lag, das durchaus seine Zeit dauert, und wir haben die Erfahrung gemacht, dass die Spieler lieber einen angekündigten Neustart anstelle eines geplanten, aber schwer vorhersehbaren Lags hätten. Selbst wenn der Neustart insgesamt mehr Zeit in Anspruch nimmt.


    Falls der verwendete V-Server prinzipiell mehrere Threads unterstützen würde - also falls sich die GC-Performance durch deren Verwendung effektiv steigern ließe - kann ich auch noch Parameter vorschlagen, die auf die Menge der Kerne/Threads angepasst sind. Wären diverse zusätzliche Parameter, von denen interessanterweise kaum ein MC-Serverbetreiber je Notiz genommen hat. Müsste in dem Fall nur wissen, wie viele Kerne nutzbar sind und wie viele Threads pro Kern höchstens Sinn machen würden, ehe keine Performance-Steigerung mehr auszumachen ist.

    wo soll ich die Parameter in die zeile einfügen?
    ich hab verschiedenes versucht aber ich bekomm immer sofort folgendes: "[screen is terminating]"
    oder brauche ich dafür noch irgend ein zusatz Programm?

    An welcher Stelle du sie einfügst, ist eigentlich relativ egal - ich würde nur vorschlagen, -jar irgendwas.jar ans Ende zu packen. Bei welchen Parametern genau kommt denn der genannte Fehler?

    Hier noch die ausführliche Antwort:


    1. Das mit den GC-Logging-Parametern:
    screen -s minecraft java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -Xmx1G -jar minecraft_server.jar nogui


    2. Das mit dem Train-GC:
    screen -s minecraft java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -Xincgc -Xmx1G -jar minecraft_server.jar nogui


    3. Das mit dem CMS-GC:
    screen -s minecraft java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -server -XX:+UseConcMarkSweepGC -XX:-UseParNewGC -Xmx1G -XX:NewSize=384M -XX:MaxNewSize=384M -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=20 -XX:CMSTriggerPermRatio=90 -XX:CMSTriggerRatio=65 -XX:CMSInitiatingOccupancyFraction=65 -XX:CMSMarkStackSize=2M -XX:CMSMarkStackSizeMax=32M -XX:CMSRemarkVerifyVariant=2 -XX:+ExplicitGCInvokesConcurrent -XX:+NeverTenure -XX:SurvivorRatio=8 -XX:MaxGCPauseMillis=500 -XX:MaxGCMinorPauseMillis=100 -XX:CMSAbortablePrecleanWaitMillis=100 -XX:CMSMaxAbortablePrecleanTime=2000 -XX:+CMSClassUnloadingEnabled -jar minecraft_server.jar nogui


    Ich würde an der Stelle empfehlen, -Xms generell wegzulassen. Hat sich bei unseren unzähligen Tests nie als nennenswert vorteilhaft herausgestellt, den überhaupt zu verwenden - Java reserviert sich auch selbst den RAM, den es benötigt, eben bis hin zu -Xmx (zzgl. etwaiger Speicherbereiche, die der GC zusätzlich braucht). Je mehr Freiheit Java dabei hat, desto besser. Auch wenn durch das Reservieren weiterer Speicherbereiche (also wenn Java das entscheidet, ohne -Xms) ein verschwindend geringer Performanceverlust besteht.