Server Ram Verbrauch !?Bukkit

[GameStalkerHD]

Hallo liebe Community

ich habe folgendes Problem und zwar ist bei meinen Server der Ramverbrauch ziemlich hoch nach der Zeit.
Was jetzt nicht wirklich störend ist.

Das Problem ist allerdings der Ram nicht wieder runtergeht.
Das heißt der Server frisst immer mehr und mehr Ram bis irgendwann Schluß ist.

Ich habe den Server anfangs bei Nitrado gehabt und dann habe ich auf einen Root gewechselt.

Es ist neuste Java Version drauf "Java 7".

Bei Nitrado hatte ich vorher einen Ram Verbrauch von ca 2,5GB Ram und jetzt sind es schon über 4 GB !!

Kennt sich da einer aus und könnte einen Tipp geben ?
Liegt es an den Start Parametern oder an was kann es liegen ?

Der Server hat insgesamt 10 GB Ram und 100 Slots.

Danke schonmal im vorraus​

 

[herberti]

Wie rufst du denn den RAM-Verbrauch auf?
Gib in der Shell "top" ein und schreib was ausgegeben wird.

 

[Crafter6432]

1. Kannst du nicht normal Schreiben?
2. Wie sieht dein Startscript aus
3. Server.log
4. Plugins
5. Daten vom Root sowie die ausgaben von "free -m" und "top"

 

[Chrisliebaer]

Das ist absolut normal. Du stellt der Java-VM eine bestimmte Menge RAM zur verfügung und den nutzt sie! Das ist ganz einfach. Die Garbage Collection in Java wird erst dann aktiv, wenn der Speicher ausgeht.

Das heißt also, dass der von dir vergebene RAM quasie IMMER gut gefüllt sein wird. Denn das freimachen von Speicher kostet Zeit und um performant zu werden, macht die JVM das erst dann, wenn der Speicher knappt wird.

Das Gerückt, dass Minecraftserver 16GB RAM brauchen hält sich aber ständig. Ich muss da immer drüber schmunzeln. Denn wie du bereits festgestellt hast: Es läuft.

 

[GameStalkerHD]

1. Kannst du nicht normal Schreiben?
2. Wie sieht dein Startscript aus
3. Server.log
4. Plugins
5. Daten vom Root sowie die ausgaben von "free -m" und "top"

1.Nein kann ich nicht...

2. 19935 GameStal 20 0 9477m 6.0g 12m S 44 9.5 193:05.08 java -Xms8192M -Xmx8192M -jar craftbukkit-1.4.7-R1.0.jar nogui

3.Serverlog ist fehlerfrei . Hab den gerade nicht vorliegen deshalb(bin auf Arbeit)

4.Plugins : http://www7.pic-upload.de/06.02.13/todyc8rn5hw5.jpg

4. total used free shared buffers cached
Mem: 64561 18564 45997 0 195 3876
-/+ buffers/cache: 14492 50069
Swap: 0 0 0


5. Daten vom Root :
Mainboard Model: Intel S5400SF
Arbeitsspeicher 64 GB DDR-2 FB ECC registerd
Grafikkarte ATI Rage Video controller with 32 MB memory
Format
19 Zoll ATX Server mit 1 Höheneinheiten (1HE)
Anschlüsse 2 x Netzwerk - Ethernet 10Base-T/100Base-TX/1000Base-T - RJ-45;
3 x Hi-Speed USB - USB Typ A, 4-polig ( Vorderseite: 1 );
2 x Display / Video - VGA - HD D-Sub (HD-15), 15-polig ( Vorderseite: 1 );
1 x Tastatur - generisch - Mini-DIN (PS/2-Typ), 6-polig;
1 x Maus - generisch - Mini-DIN (PS/2-Typ), 6-polig;
1 x seriell - RJ-45

 

[Crafter6432]

Versuch das mal und entferne die IP aus deinem Post.

java -Xms8192M -Xmx8192M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalPacing -XX:ParallelGCThreads=8 -XX:+AggressiveOpts -jar craftbukkit-1.4.7-R1.0.jar nogui

 

[GameStalkerHD]

Versuch das mal und entferne die IP aus deinem Post.

java -Xms8192M -Xmx8192M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalPacing -XX:ParallelGCThreads=8 -XX:+AggressiveOpts -jar craftbukkit-1.4.7-R1.0.jar nogui

Ich teste es mal. Ich gebe dir gleich Rückmeldung

- - - Aktualisiert - - -

Das spuckt der Server jetzt aus

nrecognized option: -XXarallelGCThreads=8
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Server läuft auf linux übrigens

Edit: Okay hab ihn zum laufen bekommen war Fehler drinne allerdings bringt es keine Veränderung

 

[Netto Hikari]

Also für mich klingt es nach einem Memory Leak. Vielleicht irgendein Plugin, wo ein Loop nicht beendet wurde oder so. Oder vllt. liegen zu viele Entities auf der Map... Hmm. Das kann viele Ursachen haben.

Versuch das mal und entferne die IP aus deinem Post.

java -Xms8192M -Xmx8192M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalPacing -XX:ParallelGCThreads=8 -XX:+AggressiveOpts -jar craftbukkit-1.4.7-R1.0.jar nogui

Nein, nein und nochmals NEIN! Daran muss ich einige Sachen kritisieren...

• -Xms sollte man nicht angeben, das entscheidet die JVM ganz gut selbst ... Wenn man es schon angeben will, dann soll man den von Bukkit direkt nach dem Start genutzten Speicher angeben ...
• Den Garbage Collector braucht man auch nicht selbst zu wählen, das macht Java auch super selbst... -XX:+UseG1GC kann man gerne angeben, aber der ist in Java 7 eh Standard und reicht aus!
• Dasselbe gilt für die Garbage Collector Threads... Daran rumzufummeln ist in 90% der Fälle eher kontraproduktiv und Performanceschübe sind viel mehr ein Placebo-Effekt.

-server, -XX+AggressiveOpts und -XX:UseFastAccessorMethods sind die einzigen "Nice-to-have"-Flags, die OK sind. Alles andere ist sinnfrei und schaden mehr als sie nützen. Wenn man sowas "tunen" möchte, dann bedeutet das häufig wochenlanges Testen und hängt vom jeweiligen System ab.

java -server -Xmx8G -XX:+UseG1GC -XX:MaxPermSize=256m -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -jar craftbukkit.jar

Ich bin auch so nett und erkläre nochmal die einzelnen Flags.

-server sagt Java, dass die Server-VM verwendet werden soll. Das sollte unter 64-Bit-Betriebssystemen / Java-Versionen Standard sein (glaube ich). Die Server-VM zeichnet sich durch bessere Performance auf Kosten der Warmup-Zeit aus.

-Xmx8G sollte selbsterklärend sein. Maximum Heap Size und so.

-XX:+UseG1GC sollte auch Standard sein... Glaub seit JRE 7 Update 4... Oder Update 9... Kann man trotzdem angeben, wenn man sich nicht sicher ist. Dieser Garbage-Collector soll einen guten Algorhitmus für größere Heap Sizes haben.

-XX:MaxPermSize=256m ist standardmäßig niedriger eingestellt und legt die maximale Größe des Platzes für Objekte fest, die permanent im Speicher residieren. Bringt auf jeden Fall viel, wenn man z.B. viele permanent geladene Chunks hat. ´

-XX:+AggressiveOpts aktiviert die eine oder andere Optimierung. Ich habe damit gute Erfahrungen gemacht. Muss aber nicht bei jedem so sein.

-XX:+UseFastAccessorMethods verringert die Zeit, die es braucht, um auf primitive Datentypen zuzugreifen.

Schlusswort: Im Grunde sind weniger Flags (bzw. nur Standardflags) am Besten, da - ich sags noch en letztes Mal - Java selbst am Besten entscheiden kann, was gut ist und was nicht.

 

[Calenria]

Was unter Umständen noch was bringen kann ist -XX:+UseLargePages, allerdings muss man dafür einiges am System anpassen

 

[Netto Hikari]

Jupp. An Hugepage-Support muss ich auch schon die ganze Zeit denken. Habe es aber nicht erwähnt, da das Bearbeiten der sysctl.conf und / oder das Selbstkompilieren des Kernels nicht wirklich für Laien gedacht ist.

 

[Sascha72036]

Liegt an Plugins

Also bei mir lag das immer an den Plugins.

Wenn du willst dann helfe ich dir auch so die Plugins sauber einzurichten.

Grus
Sascha