Bukkit - Minecraft, Prozessor-Auslastung sehr hoch

Eventuelle Chunkfehler auf der Map? Entferne die Map mal und die Mods. Einfach ein rohes Bukkit. Danach wieder Map dazu und dann ein Plugin nach dem anderen ...

Die Auslastung muss nicht zwingend von Bukkit selbst kommen - unter Umständen wählt, da du keine diesbezüglichen Parameter angeht, Java irgendeinen GC aus, den du vllt. eher nicht haben möchtest. Füge mal den Parameter -Xincgc hinzu. Und beachte, was Alex sagte. Also -Xmx3G dazu noch beispielsweise.

Mit -Xmx legst du fest, wieviel RAM Java maximal verwenden darf (wobei da noch ein paar Kleinigkeiten obendrauf kommen) - ohne -Xms würde Java sich nun erstmal nur soviel nehmen, wie es benötigt. Also sobald es mehr RAM benötigt und seitens -Xmx immernoch Spielraum nach oben ist, dann würde Java mehr RAM reservieren. Mit -Xms kannst du festlegen, wieviel RAM Java direkt von Anfang an reservieren soll. Der Vorteil davon, -Xms zu setzen, liegt m.E. darin, dass Java weniger häufig mehr RAM reservieren muss, was jedesmal auch etwas Rechenzeit benötigt. Andererseits empfinde ich diesen zusätzlichen Bedarf an Rechenzeit als so geringfügig, dass ich persönlich auf -Xms grundsätzlich verzichte - zumal ich auch schon in der Situation war, wo Bukkit durch die Verwendung von -Xms mit dem gleichen Wert wie -Xmx plötzlich einen OOM rauswarf (nein, kein 32-Bit-System), was vorher ein halbes Jahr lang ohne -Xms nie passierte. Wieso auch immer, aber das hat mich auch ein wenig abgeschreckt.

Palim Palim

Ich nutzde den "originalen" mc server und habe normalerweise eine CPU auslastung von ca 14% (wen der server lehr ist).
Wobei der server seit einigen Tagen weniger auslastung hat als sonst... momentan liegt der MC Server bei 3-6%.(4GHz)
Gestartet wird der server seit einigr zeit über einen crontab regelmäsig neu.
Ich habe damals mal diesen Startbefehl übernommen gehabt.

"java -Xmx4096M -Xms4096M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalPacing -XX:ParallelGCThreads=$CPU_COUNT -XX:+AggressiveOpts -jar minecraft_server.jar nogui"

Bis jetzt läuft es eigendlcih ganz ok.

lg DasUFO

Ich frage mich... -XX:+CMSIncrementalPacing hat doch eigentlich keine Wirkung, wenn der -XX:+CMSIncrementalMode nicht aktiviert wird. Und bevor man den IncrementalMode aktiviert, kann/sollte man eher noch zum G1GC greifen, der genau das macht, nur ohne dabei Heap-Fragmentierung zu erzeugen. Und da als Minor-GC auch nicht -XX:+UseParNewGC eingesetzt wird, also da hierfür der Serial-GC (Single-Threading) verwendet wird, ist -XX:+ParallelGCThreads=$CPU_COUNT ebenfalls wirkungslos. Beinhaltet die CPU-Leistung, die man bei den VServern bekommt, eigentlich mehrere Threads, die man parallel verwenden könnte, so dass damit im Vergleich zu Single-Threading auch eine Performance-Steigerung messbar ist? Wenn ja, könnte man zumindest für den CMS-GC, falls man den IncrementalMode aktiviert, die verwendeten Threads mittels der folgenden Parameter erhöhen:

-XX:+CMSConcurrentMTEnabled -XX:ConcGCThreads=<a> -XX:ParallelGCThreads=<b> -XX:ParallelCMSThreads=<a+b>

Die beiden Parameter in Fettschrift sind hierbei für Multithreading beim CMS-GC, egal ob im normalen oder im inkrementellen Modus. Zu beachten sei hierbei, dass ParallelCMSThreads mindestens ConcGCThreads+ParallelGCThreads sein muss - das gibt einfach nur die Gesamtmenge an Threads an, die MinorGC+MajorGC zusammen verwenden dürfen. Aus dem Grund habe ich ParallelGCThreads hier auch mit reingeschrieben, auch wenn dieser Parameter weder auf den CMS-GC (MajorGC) noch auf den Serial-GC (MinorGC) Auswirkungen hat. Falls Multithreading vorhanden ist, müsste man noch den oben erwähnten Parameter -XX:+UseParNewGC hinzufügen, damit als MinorGC der mit Multithreading verwendet wird, womit dann auch -XX:ParallelGCThreads eine Wirkung hat, indem es bestimmt, wie viele Threads der ParNewGC verwenden darf.

hmm dan ist das wie ich den server starte totaler Blödsin?
Was würdest du den empfehlen?

lg

Kommt ganz drauf an, wie du die GCs arbeiten lassen möchtest bzw. wieviel Performance du für die GCs opfern möchtest. Du kannst zum Beispiel erstmal schauen, ob das, was ich sage, überhaupt stimmt, indem du die Parameter, die ich als wirkungslos bezeichne, testweise einfach rausnimmst. Am besten GC-Logs vor sowie nach der Änderung machen, damit du die direkt vergleichen kannst. Damit du die inhaltlich möglichst detailliert hast, kannst du folgende Parameter einfügen:

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

Seit dem neuesten Java7-Update teste ich bei unserem MC-Server nach längerem mal wieder den G1GC (vorher den CMS-GC mit ParNewGC), und zu meiner Überraschung arbeitet der inzwischen RICHTIG gut und effizient. Mit dem CMS kann er in jedem Fall gleichziehen, nur dass die Nachteile des CMS (RAM-Fragmentierung und dadurch langsam abnehmende CMS-GC-Performance) dabei vermieden werden. Bin allerdings noch am austesten, welche Parameter nun seit dem neuesten Update den G1GC überhaupt beeinflussen und welche nicht. Mehr dazu weiter unten - hier zunächst die Parameter, die wir derzeit verwenden:

-server -XX:+UseG1GC -Xmx10G -XX:ParallelGCThreads=4 -XX:ConcGCThreads=4 -XX:G1HeapRegionSize=4M -XX:MaxGCPauseMillis=90 -XX:MaxGCMinorPauseMillis=90 -XX:SoftRefLRUPolicyMSPerMB=4000 -XX:SurvivorRatio=8 -XX:+NeverTenure -XX:UseSSE=3 -oss4M -ss4M -XX:+AggressiveOpts -XX:+DisableExplicitGC

Und im Folgenden noch die Erklärungen zu den einzelnen Parametern - sind diesmal ja nicht so viele...

-server: hat neben generell höherer (GC-)Performance u.a. die Eigenschaft, dass im Gegensatz zu -client Soft-References weniger aggressiv gelöscht werden, womit sich ein Bug, bei welchem Redstone-Torches positionsbezogen dauerhaft (bis zum Server-Restart) ausgebrannt bleiben, eindämmen lässt.

-XX:+UseG1GC: G1 aktivieren (man braucht in diesem Fall keinen MinorGC anzugeben, da G1 sowohl MajorGC als auch MinorGC verwaltet)

-Xmx10G: Wir nutzen 10 der 16 GB RAM unseres Servers. Sollte man natürlich jeweils an die RAM-Ressourcen seines Servers anpassen - je nachdem, wieviel man MC geben möchte.

-XX:ParallelGCThreads=4 und -XX:ConcGCThreads=4: Unerwarteterweise verhält sich der G1 seit dem neuesten Java7-Patch bei diesen Parametern so wie der CMS-GC. Mittels ParallelGCThreads sagt man ihm, wie viele Threads bei MinorGCs zu verwenden sind, und den bei ConcGCThreads eingetragenen Wert nimmt er als Thread-Anzahl für MajorGCs, obwohl vor längerem mal gesagt wurde, dass der G1 zwischen Minor und Major überhaupt nicht mehr unterscheidet. Er tut es laut Logs nun jedenfalls. Diese Werte sollte man an die nutzbaren CPU-Cores anpassen für optimale Performance.

-XX:G1HeapRegionSize=4M: Gibt an, wie groß die einzelnen Regionen sind, die der G1 jeweils abarbeiten soll. Zwischen 1M und 32M. Tests haben dabei ergeben, dass mit 4M die durchschnittlich beste Performance erzielt wird.

-XX:MaxGCPauseMillis=90 und -XX:MaxGCMinorPauseMillis=90: Ersteres gibt einen Richtwert vor, wie lange die StopTheWorld-Phasen (in denen der MC-Server komplett angehalten wird) maximal dauern sollten. Zweiterer Parameter dürfte beim G1 vollkommen nutzlos sein, hat jedoch beim CMS-GC einen Nutzen, weshalb ich ihn hier auch mal teste.

-XX:SoftRefLRUPolicyMSPerMB=4000: Der weiter oben schon erwähnte Bug mit den dauerhaft ausgebrannten Redstone-Torches lässt sich durch Anheben dieses Wertes (Standardwert: 1000) praktisch komplett aus der Welt schaffen. Ich habe es in 500er-Schritten angehoben, bis der Bug laut unseren Spielern nicht mehr auftrat. Ab 4000 war das dann der Fall.

-XX:SurvivorRatio=8 und -XX:+NeverTenure: Die bedeuten im Prinzip beide soweit das gleiche, wobei der Wortlaut von NeverTenure nicht wörtlich zu nehmen ist. Sie bewirken, dass möglichst wenige Daten von der jungen Generation in die alte Generation aufsteigen - denn wenn sie erstmal dort sind, kriegt man sie nur schwer wieder raus. Zumindest für den CMS-GC gilt das - da sich der G1 in vielerlei Hinsicht wie der CMS verhält, teste ich derzeit aus, ob die Nutzung dieser Werte beim G1 einen Unterschied macht. Und mir sieht es so aus, als sei das der Fall: lasse ich die Parameter weg, läuft der RAM langsam voll, bis nach einer Weile ein Out Of Memory kommt - also offensichtlich verbleiben nutzlose Daten im RAM. Der verwendete RAM nimmt dabei einfach nicht mehr ab, wenn der eigentliche RAM-Bedarf des Servers abnimmt. Mit den Parametern (bzw. theoretisch schon mit einem davon) wird nicht mehr benötigter RAM auch wieder freigegeben, statt dass nutzlose Daten sich zunehmend ansammeln.

-XX:UseSSE=3 -oss4M -ss4M -XX:+AggressiveOpts: Nur ein paar Optimierungen, die ich von Zeit zu Zeit neben anderen austeste. So wirklich konnte ich bisher keine Vorteile beobachten, auch wenn zumindest durch SSE welche vorhanden sein müssten. In der Vergangenheit hat AggressiveOpts mal für Crashes gesorgt - da sich die Auswirkungen dieses Parameters allerdings prinzipiell von Java-Version zu Java-Version ändern können, teste ich es nach jedem Update mal. Und seit dem neuesten Java7-Update sind damit keine Crashes mehr aufgetreten.

-XX:+DisableExplicitGC: Verhindert, dass von innerhalb des Programms (also durch den MC-Server oder durch Plugins) MajorGCs ausgelöst werden können - also mit diesem Parameter entscheidet der GC allein, wann und wie er aktiv wird. Durch Plugins, die das mitentscheiden, büßt man sonst unter Umständen eine ganze Menge Performance ein, ohne Vorteile davon zu haben.

hej ho

Ich werde das mal ausprobieren aber mit weniger Ram habe ja nur 2gb + 4gb flexi
Aber woher bekomme ich die anzahl der cores? ich habe 4ghz bei meinen vserver. bei htop zeigt der mir

1  [###########################***************                                       	44.7%] 	Tasks: 115 total, 1 running
  2  [#####################*******                                                     	29.8%] 	Load average: 0.06 0.02 0.00 
  3  [##################################################################################**100.0%] 	Uptime: 6 days, 13:46:13
  4  [##################*****                                                          	24.7%]
  5  [###########***                                                                   	14.6%]
  6  [##################################**********                                     	47.4%]
  7  [########**                                                                        	9.3%]
  8  [########******                                                                   	14.7%]
  9  [####################*******                                                      	28.7%]
  10 [######****                                                                       	10.7%]
  11 [#*                                                                                	1.3%]
  12 [|############****                                                                	17.1%]
  13 [########***                                                                      	11.3%]
  14 [#######*****                                                                     	11.8%]
  15 [#######**                                                                         	9.3%]
  16 [####################################******                                       	46.0%]
  Mem[||||||||||||||||*******                                                     	358/2048MB]
  Swp[                                                                              	0/4096MB]

an. aber 16 kann ihrgendwie nciht hinhauen oder?

Ah verstehich
dan kan ich ja die anzahl der cores von 1 nach oben koregieren
Ich habe vorhin ein screenshot von htopm mit 126 cores gesehen

Ich habe grade die Parameter getestet und mus sagen das es flüssiger läuft als voher und der Ram bleibt weitestgehend Konstant.
mehr wird sich aber dan die tage rausstellen wen mal mehr als nur 1 aufen server läuft.
aber vielen dank schonmal

Dann könnte man es sich also zumindest erlauben, so 4 Threads für die GCs einzustellen, oder? Bzw. würde das in Anbetracht der Art der Virtualisierung überhaupt Sinn machen?

r.neumann, nein. Du weißt ja nicht, welche anderen Prozesse noch laufen. Du müsstest Wissen, wieviele Cores ingesamt dir zur Verfügung stehen. Dann könntest du $cores_exklusiv-1 einstellen, wenn auf dem vServer sonst absolut nichts anderes läuft.

Quote from [netcup] Alex

Doch natürlich Die vServer sind nicht "per Core" limitiert sondern in der Leistungsaufnahme der verfügbaren Cores.

Das merkt man sehr gut wenn man mal -j12 beim Kompilieren setzt. Kurzzeitig gibt es 12 Prozesse, dann aber schon nach wenigen Sekunden bekommen nur noch 1 oder 2 Prozesse CPU-Zeit zugewiesen und die restlichen 10 Dümpeln in der Warteschlange rum. Und damit würde, r.neumann, dein Minecraft-Server ganz komischen Schluckauf haben und sicherlich sporadisch Ruckeln, weil einige Threads dann quasi verhungern.

Alex, kann man das Core-Limit in Erfahrung bringen?

Hmmm, das Ruckeln, wie du es beschreibst, hat einige Ähnlichkeit mit dem, was hier von manchen beschrieben wird. Ich kann da jetzt im Moment offen gestanden nicht wirklich mitreden, da mein MC-Server auf einem nicht virtualisierten Rootserver läuft, aber vor langer langer Zeit (bis Beta 1.7) hatte ich den auch noch auf einem V-Server, auf welchem ähnliche Ruckler von Zeit zu Zeit vorkamen - möglicherweise eine gemeinsame Ursache und in dem Sinne ein Grund, bei bestimmten Virtualisierungen MC/Bukkit auf einen Thread zu beschränken. Gibt ja sonst je nach GC-Wahl durchaus die Möglichkeit, dass Java dem GC einfach pauschal mehrere Threads zuteilt, wenn man es nicht explizit auf 1 festlegt. Selbiges bei diversen Bukkit-Plugins, die ja teilweise auch die Möglichkeit auf Multithreading bieten. Denke, dem sollten die von euch, die über NetCup-VServer diverse Gameserver hosten, generell mal nachgehen - nicht nur auf Minecraft bezogen.