Minecraft Serverinfo und Regeln

[TheJester]

Nachtrag: klar kann man das auch lösen indem man irgendwoher Speicher zaubert oder das ganze umzieht, aber ich halte das für keine Lösung. Die Weltverzeichnisse sind innerhalb von 2 Wochen um bald 30% gewachsen (5GB worlddata jetzt, ohne world4), und wenn das weiter so exponentiell wächst stösst man da früher oder später wieder an seine Grenzen.

Alles was man so an ftb Servercommunities sieht ist mit 3-5 Playern bei um die 12gb ram, und wir haben insgesamt einige Player mehr.

Wenn wir rausfinden könnten was da wirklich Speicher leaked (welches Mod, welche Java Datei, welcher Blocktyp) würde das schon weiterhelfen, dann könnten wir das ja auch bis zum modupdate vermeiden.

[TheJester]

Noch ein Update:

Also ich hab mal etwas lokal mit der VisualVM herumgesucht, aber wie zu erwarten war sieht man eh erstmal größtenteils Instanzen von SDK Klassen, und zudem sind die ganzen Minecraftklassen alle obfuscated.

Aber der gc und die cpuzeit reagieren zumindest genauso wie ich es erwartet habe, das geht total in die Knie wenn der da Memorylimit erreicht.

Auf dem Server läüfts derzeit eine Stunde lang völlig stabil. Leider hat der sich beim kopieren lang gemacht, d.h. das ist das Backup von heute Nacht 0:30.

Ich beobachte den jetzt mal weiter, hoffe das wars fürs erste. Und dann mal einen Plan wie wir unsere Umwelt sauberhalten können. Auch ne art von Smog

[Elinnar]

Danke für die Arbeit und das ganze debugging *allhailthejester*

keine ahnung wie man da am besten hinter kommt o_O*
Grade um 15Uhr ist der Server nach dem Stündlichen Restart auch nicht wieder alleine hoch gekommen irgendwie

[x3t0]

HAIL HAIL HAIL

ich würde vorschlagen, man macht eine allgemeine miningwelt und nicht jeder eine einzelne. Alle alten, nichtbenutzen welten dann löschen. Lager nur noch in türmen um chunks zu sparen und ansonsten die "moral des sparens" ... nur so viele maschinen wie man braucht!

[GreenDotP]

Cool, wie viel Zeit du dir dafür nimmst, Jester.
Gute Vorschläge von x3t0.

[Dave]

Moin...
Fahre gerade nach Hause, und wollte mal ins Forum schauen.
So wie es aussieht braucht Beate wieder liebe (oh ja, ich habe unsrem ftb Server gerade einen Namen gegeben)

Von dem was ich hier lese habe ich auch schon grobe Ideen

sehen uns heute Abend online, vielleicht kann ich ja irgendwie helfen. Will ja auch spielen wieder.

[GreenDotP]

Here he comes to save the day!

[jomu78]

Hohe CPU Last bei Memory-Limit ist normalerweise immer die GC, die versucht noch irgendwo das eine oder andere Byte rauszuquetschen.
Kann sein, dass der server selbst versucht GC zu steuern (via Sytem.gc()) - gerade wenn viel dyn. erzeugt wird. Das geht häufig schief - deshalb kann man es abschalten mittels: -XX:+DisableExplicitGC

Die Debug Ausgabe der GC kann auch hilfreich sein: -verbose:gc

Man könnte versuchen -Dsun.rmi.dgc.server.gcInterval=1800000 und -Dsun.rmi.dgc.client.gcInterval=1800000 zu setzen, um alle 30min die GC für RMI Objkete zu forcieren. (bin mir gerade nicht sicher, ob das eine gerenelle Einstllung ist, oder Glassfish spezifisch).

[Dave]

meiner meinung nach ist das ursache<->wirkung prinzip bei dieser diskussion off.

es geht doch nicht darum, wie man nen server am memory limit am leben hält, sondern wieso der server plötzlich in 1 stunde 4,5GB ram verbrät.
und ich denke, das kann man nur "von innen" finden, weil wieder block a auf block b sitzt, und dann genau das passiert...

beate braucht halt liebe... aber ich hab grad so null bock auf nix... ausser auf essen! bin in der küche (:

[Dave]

da ich dazu neige, manchmal pampig zu schreiben, wenn 1000 sachen laufen, und ich nur nebenbei tippe:

jomu, stand ausser frage, das das nen mega kompetenter beitrag war, aber ich persönlich denke aus erfahrungen mit beate, dass das eine inter-mod-inkompatiblität ist, die einfach ein langsames memory leak triggert. das heisst auch noch so perfekte GC einstellungen oder 10-facher speicher schiebt das problem nur nach hinten... so, küche *lol*

[Lazh]

also, erstmal vielen vielen dank an euch, die ihr euch da soviel mühe macht

ich fänds gut, wenn die leute die sachen die schon weltentode verursacht haben, beseitigen/ersetzen würden, sofern noch vorhanden.
also explizit:
Xycraft-Tanks
Induction Furnace mit angeschlossenen Pipes (war doch das bei Tims Weltentod?)

ausserdem würd ich jedem das ME Storage und Bus-system von Applied Energistics empfehlen, da das problem bei pipes das ist, dass wenn item rausfallen, sie als Entities spawnen und massive lags verursachen. das problem gibts bei dem ME Zeugs ned.

zum anderen.. kann man in den serverlogs raussuchen was den server killt, würd mich auch bereit erklären mich da mal durchzuwühlen. jester meinte mal was von problemen/exceptions bei xycraft

[TheJester]

Das was der Server schreibt sind crashlogs, also immer dann wenn er sich wirklich langgemacht hat. Aber da kann man auch nur raten was das ist, bzw sieht die Klasse wo es abgeraucht ist.

Allerdings sind die wirklichen Crashes ja nun eher selten. Bei dem Speicherverbrauch wird man da leider nicht fündig

[Elinnar]

Heute scheint der server teilweise nur bis minute 40-45 durchzuhalten, was ich gesehen hab ist das er ab 5.3GB speicher angefangen schwierigkeiten zu machen. Teilweise scheint er dann bei automatischen neustart nicht wieder zu starten vermutlicht weil er zu lange zum stoppen braucht.

Was im server log auffällt wären folgende zwei events

2013-05-13 19:59:27 [WARNING] [IC2] API ERROR: powercrystals.powerconverters.power.ic2.TileEntityIndustrialCraftConsumer@59fd874f (0:-1528,27,158) didn't implement demandsEnergy() properly, no energy from injectEnergy accepted (256) although demandsEnergy() requested 256.


2013-05-13 20:57:55 [INFO] [STDERR] java.util.ConcurrentModificationException
2013-05-13 20:57:55 [INFO] [STDERR]     at java.util.HashMap$HashIterator.nextEntry(HashMap.java:839)
2013-05-13 20:57:55 [INFO] [STDERR]     at java.util.HashMap$ValueIterator.next(HashMap.java:868)
2013-05-13 20:57:55 [INFO] [STDERR]     at bq.a(SourceFile:24)
2013-05-13 20:57:55 [INFO] [STDERR]     at cd.a(SourceFile:114)
2013-05-13 20:57:55 [INFO] [STDERR]     at bq.a(SourceFile:25)
2013-05-13 20:57:55 [INFO] [STDERR]     at by.a(SourceFile:26)
2013-05-13 20:57:55 [INFO] [STDERR]     at cd.a(SourceFile:114)
2013-05-13 20:57:55 [INFO] [STDERR]     at bq.a(SourceFile:25)
2013-05-13 20:57:55 [INFO] [STDERR]     at cd.a(SourceFile:114)
2013-05-13 20:57:55 [INFO] [STDERR]     at bq.a(SourceFile:25)
2013-05-13 20:57:55 [INFO] [STDERR]     at cd.a(SourceFile:114)
2013-05-13 20:57:55 [INFO] [STDERR]     at ca.a(CompressedStreamTools.java:140)
2013-05-13 20:57:55 [INFO] [STDERR]     at aam.a(AnvilChunkLoader.java:198)
2013-05-13 20:57:55 [INFO] [STDERR]     at aam.c(AnvilChunkLoader.java:184)
2013-05-13 20:57:55 [INFO] [STDERR]     at aiw.b(SourceFile:29)
2013-05-13 20:57:55 [INFO] [STDERR]     at aiw.run(SourceFile:22)
2013-05-13 20:57:55 [INFO] [STDERR]     at java.lang.Thread.run(Thread.java:722)

Interessant ist auch wie inkonsistent er zu leaken scheint, offenbar ist das nicht konsisten sonder gelegentliche "schübe" die dann etwa 100-300MB in etwa 20sec hoch setzen die natürlich nicht wieder frei gegeben werden \O/

Derzeit haben meines wissens folgende Leute ihre chunkloader abgebaut
Rausch/Dave
Mooni/Elinnar
Lazh
Xeto

[Rausch]

nur die overworld chunkloader derzeit aber das war ja overworld afaik

[TheJester]

Matze meinte eben mit 1.0.2 wär ein grossteil der Leaks behoben, allerdings gäbe es einen Haufen neuer Bugs weswegen das bislang nicht released würde.. Das wär ja was..