Bukkit 1.5.2 - Dualcore vs. Quadcore

[mr.madman]

Hallo alle zusammen,

das Web ist voll mit solchen Threads, aber irgendwie bringt keiner mal ein klares Ergebnis, wie es aktuell aussieht.
In wie fern ist das Multithreading den mit der 1.5 verbessert worden? Hat der Quadcore bei niedrigerem Takt eine Vorteil gegenüber einem Dualcore?

Was macht sich besser in dem Server: ein E5700 (2 x 3.0GHz, 2MB Cache) oder ein Q6600 (4 x 2.4GHz, 8MB Cache)?

Overclocking kommt wegen dem grottigen Board und der Stromrechnung nicht in Frage, bevor hier gesagt wird, dass der Q6600 auf 3.00GHz optimal wäre ^^


Zum Hintergrund:
Hab einen Bukkit auf 1.5.2 mit Monster Apocalypse laufen. Bis vor kurzem war da noch ein stark untervolteter Celeron 420 auf 2.66Ghz drin - ich weiß der geht weiter, das Board ist aber etwas unwillig (AsRock-Müll mit DDR3).

Hatte ständig die Meldung "Can't keep up..." und CPU bei mehr als 3 Spielern immer auf 100%. RAM war so gut wie leer und an der Platte lag es nicht, der Server läuft im RAM-Drive. An der Leitung liegt es auch nicht, die hat 2.000 Upload und hatte auch noch reichlich Reserven.

Jetzt hab ich dem gestern erstmal einen E5700 verpasst, in wie fern sich das bessert kann ich erst die Tag genau testen, bisher aber noch keine Probleme aufgetreten.

Hab im HTPC aktuell nen Q6600 und überlege halt, den lieber in den Server zu stecken - will aber nicht riskieren, dass die Kiste nachher langsamer läuft obwohl er ja mehr verbraucht.

Mal eben schnell umbauen zum Testen kommt nicht in Frage, der Kühler sowohl vom Server als auch vom HTPC erfordern, dass das Board raus muss.

 

[L1qu1dat0r]

Hi da ich wirklich keine Ahnung hab wie sich der Q6600 in Bukkit schlägt (meine vermutung ist ,das er im Server besser geeignet ist als der 5700,ist zwar langsamer aber schätze das es bei Bukkit auf die Threads ankommt ,die er gleichzeitig
abarbeiten kann) hab ich hier ein Benchmarktest gefunden.Intel Core 2 Quad Q6600 vs Pentium E5700
Der TDP 105W Q6600/ 65W E5700 ist natürlich schon ne Hausnummer,wenn der E5700genügend Leistung hat, würd ich den aus Wirtschaftlichen Gründen drinnen lassen.


MFG

 

[mr.madman]

Danke für die Antwort.

Von der Leistung her, ist er natürlich deutlich schneller.

Das Problem war ja immer, das Minecraft komplett Single-Threaded war. Irgendwann um die 1.3 rum wurden dann immerhin schon mal die Chunks in eine separaten Thread ausgelagert.

Was man so an Informationsfetzen findet ist, dass der Bukkit im Vergleich zum Standard-Server schon sehr viel in Sachen Multithreading macht.

Aktuell kann ich beobachten, dass beide Kerne immer schön gleichmäßig belastet werden, also scheint es da schon massive Fortschritte zu geben.

Von der TDP hab ich auch lange gegrübelt, über 100W sind schon ne Hausnummer, da der die aber nur unter Volllast erreicht und Sachen wie Speedstep etc. wunderbar funktionieren, würde er ja nur unter Last richtig fressen und eben bei Bedarf die Reserven haben (natürlich ist klar, dass selbst die Leerlaufleistung des Q6600 höher als die des E5700 ist).

Werde das Risiko heut mal eingehen und mir die Mühe machen umzubauen. Hoffentlich geht das Multithreading auch bei mehr als 2 Kernen ^^


Edit:

Wenn andere danach suchen:

4 x 2.4GHz laufen langsamer als 2 x 3.0Ghz - obwohl die 4 Kerne laut Task-Manager gleichmäßig benutzt wurden

4 x 3.0GHz laufen identisch zu 2 x 3.0GHz

aktuell läuft jetzt der E5700 auf 2 x 3.5GHz ... Performance ist optimal.


Das Ganze hab ich dann nochmal mit 1, 2, 3 und 4 Kernen probiert ... das Ergebnis ist, dass Bukkit auch in der 1.5.2 nur 2 Kerne sinnvoll nutzt, danach skaliert die Leistung mit mehr Kernen nur in Ausnahmesituationen - deutlich besser skaliert Bukkit mit Takt.

 

[L1qu1dat0r]

In Optifine gibt es doch die Einstellung Multicore supportet.
Vlt bekommst du damit die 4 Kerne ausgelastet ??

Ist klar das mehr Takt meist auch mehr Leistung bedeutet.
Selbst wenn alle vier Kerne ausgelastet sind heißt das noch nicht ,das der Server schneller läuft.
Soweit ich weiß,berechnet Minecraft die Chunks schneller mit Optifine.(Multicore support)

 

[Shona]

Das Ganze hab ich dann nochmal mit 1, 2, 3 und 4 Kernen probiert ... das Ergebnis ist, dass Bukkit auch in der 1.5.2 nur 2 Kerne sinnvoll nutzt, danach skaliert die Leistung mit mehr Kernen nur in Ausnahmesituationen - deutlich besser skaliert Bukkit mit Takt.

Wieso willst du Bukkit überhaupt auf 4 Kernen nutzen? O.o

Bukkit/Vanilla Server brauchen mehr RAM als CPU, da kannste den auch auf einem Kern laufen lassen würde sich InGame nichts ändern. So läuft das bei uns seit einer Weile auf dem Rootserver und es gibt keine Performanceänderungen InGame.

Die Meldung "Can't keep up..." kam bei unserem Bukkit Server schon immer beim Start des Server und war auch schon da bevor wir auf einen Kern umgetsellt haben.

What DOES work!

There ARE some limited things you can do to eek more power out of your existing system. Check it out:
MUST... SEE... closer?? Easiest thing to do to is lower your view-distance setting in your server.properties file. The furthest view-distance you can have is 15, while the shortest is 3. If you really want to reduce lag, try the 3 setting and see if you can tolerate it. If that's too short, keep increasing the view distance until you can see far enough that it doesn't bother you.
MORE POWER Ok, so be cautions here. This is a bit of a confusing topic. Something you have to realize is that Minecraft Servers can only run on ONE CORE of a processor. Upgrading to a 6-core monster won't do you any good. However, if you get a processor that is faster per core, then you can really up your player capacity without adding any lag. The absolute best processor you can get at the time of this writing is the Intel Core i7-2700K as determined by this website. You'll see there that there are several other processors that performed better, but closer inspection will reveal that they are all 6-cores. That means that even though the 3960X has a passmark of 14,900, your server will only be able to access 2,480 of that power, compared with 2,575 with the 2700K.

Can't Keep Up - Improving Minecraft Server Performance

 

[mr.madman]

Vielen Dank - das ist man in Foren gar nicht mehr gewohnt - Hilfe ohne Getrolle, das es sowas noch gibt ^^

Zum Thema 4 Kerne nutzen wollen:
Ich stelle halt die Infrastruktur und mache den Op, das Ganze ist eher ne Art Experiment zum rantasten, was man so braucht.
Man liest überall nur viel über Sandy und Ivy, aber halt nichts, wie Cachelastig das Ganze nun ist oder wie eben ein Wolfdale, Allendale, Conroe und Co. so mit Minecraft laufen.

Vor ner Weile hatte ich mal nen Core Solo mit 1,86GHz mit 2GB als Server mit 1.3.2 für 4 Leute - hat mit wenig Plugins gereicht.


Der neue Server soll ja für 8 Leute reichen unter 1.5.2 mit Monster Apocalypse.
Als erstes war ein Celeron 420 auf 2.66GHz drin und hat nicht gereicht, da gabs öfters mal Lags und die Konsole war voll mit dem "Can't keep up" - der Dualcore hat zumindest die Lags verschwinden lassen, egal wieviele Leute on sind - die Meldung kommt immernoch, nur eben seltener.

Optifine ist ja eigentlich ein Clientmod - ich werde ich mal sehen, obs was ähnliches für Bukkit gibt - NoLagg hab ich schon versucht, brachte gar nichts.

Zum Thema Optimierung habe ich auch schon ne Menge gelesen, besonders das mit der Sichtweite hat auf meinem alten Server viel gebracht.

Mit dem RAM hab ich auch schon überlegt, aktuell bekommt Minecraft 1,5GB laut Taskmanager benutzt es meistens zwischen 400 und 500 MB

gestartet wird der Bukkit mit

java -Xms512M -Xmx1536M -jar craftbukkit.jar

Das Maximum für 32bit Java unter Windows soll ja bei 1792M liegen.

sobald ich den xmx auch nur um 1MB über die 1536M erhöhe bekomme ich folgendes:

Error occurred during initialization ov VM
Could not reserve enough space for object heap
Could not create the Java Virtual Machine

... und das obwohl genug RAM da ist und unter 32bit XP ja 2048MB pro Thread möglich sind


Aktuell überlege ich, das ganze mal auf ein 64bit Windows 7 zu bringen und dem Server mal 8GB zu geben. In die Richtung hatte ich vorher halt noch nicht überlegt, da eben nur 400-500MB benutzt werden. Der Hinweis mit dem 1 Kern und der RAM-Menge bringt mich nur heftig ins grübeln.

 

[Shona]

Vielen Dank - das ist man in Foren gar nicht mehr gewohnt - Hilfe ohne Getrolle, das es sowas noch gibt ^^

Kein Problem

Zum Thema 4 Kerne nutzen wollen:
Ich stelle halt die Infrastruktur und mache den Op, das Ganze ist eher ne Art Experiment zum rantasten, was man so braucht.
Man liest überall nur viel über Sandy und Ivy, aber halt nichts, wie Cachelastig das Ganze nun ist oder wie eben ein Wolfdale, Allendale, Conroe und Co. so mit Minecraft laufen.

Vor ner Weile hatte ich mal nen Core Solo mit 1,86GHz mit 2GB als Server mit 1.3.2 für 4 Leute - hat mit wenig Plugins gereicht.


Der neue Server soll ja für 8 Leute reichen unter 1.5.2 mit Monster Apocalypse.
Als erstes war ein Celeron 420 auf 2.66GHz drin und hat nicht gereicht, da gabs öfters mal Lags und die Konsole war voll mit dem "Can't keep up" - der Dualcore hat zumindest die Lags verschwinden lassen, egal wieviele Leute on sind - die Meldung kommt immernoch, nur eben seltener.

Optifine ist ja eigentlich ein Clientmod - ich werde ich mal sehen, obs was ähnliches für Bukkit gibt - NoLagg hab ich schon versucht, brachte gar nichts.

Zum Thema Optimierung habe ich auch schon ne Menge gelesen, besonders das mit der Sichtweite hat auf meinem alten Server viel gebracht.

Mit dem RAM hab ich auch schon überlegt, aktuell bekommt Minecraft 1,5GB laut Taskmanager benutzt es meistens zwischen 400 und 500 MB

gestartet wird der Bukkit mit

java -Xms512M -Xmx1536M -jar craftbukkit.jar

Das Maximum für 32bit Java unter Windows soll ja bei 1792M liegen.

sobald ich den xmx auch nur um 1MB über die 1536M erhöhe bekomme ich folgendes:

Error occurred during initialization ov VM
Could not reserve enough space for object heap
Could not create the Java Virtual Machine

... und das obwohl genug RAM da ist und unter 32bit XP ja 2048MB pro Thread möglich sind


Aktuell überlege ich, das ganze mal auf ein 64bit Windows 7 zu bringen und dem Server mal 8GB zu geben. In die Richtung hatte ich vorher halt noch nicht überlegt, da eben nur 400-500MB benutzt werden. Der Hinweis mit dem 1 Kern und der RAM-Menge bringt mich nur heftig ins grübeln.

So erstmal zu den 4 Kernen und welche CPU.
Das ist vollkommen uninteressant es kommt ansich nur auf den Takt der CPU laut der Seite die ich oben verlinkt habe. ich sage ganz einfach es kommt weder auf die CPU noch den Takt noch den RAM an.

Meine Erfahrung ist das es einfach darauf ankommt was auf dem Server abgeht.
Wenn dort viele Redstoneschaltungen sind die dauerhaft laufen laggt jeder MC Server egal was man macht. Dann ist uns aufgefallen das wenn nur ein einziger in Gebiete kommt die man er "entdecken" muss laggt es ebenfalls, hinzu kommt noch wenn die view-distance vom Server aus (server.properties) auf 10 bleibt. Diese kann man getrost auf das minimum von 3 runterschrauben bzw. auf 5 würde auch noch gehen. Ein weiteren Kriterium für Lags sind auch zu viele Mods bzw. unwichtige Mods die man sich auch sparen kann.

Unser Rootserver hat einen AMD Opteron™ 3280 mit 8x 2,4 GHz und 16 GB RAM. Der MC Server von uns lief bis dato immer auf allen Kernen mit 4GB RAM und wie auch schon oben erwähnt kam die Meldung gleich von Anfang an - an dem sollte es ansich nicht liegen auch wenn nebenbei noch 4-5 andere Server gelaufen sind. Den auch wenn diese aus waren, war es nicht anders.

Auf dem derzeit laufenden Tekkit Server ist es nicht anders, sobald er neugestartet wurde ist das erste was kommt "Can't keep up! Did the system time change, or is the server overloaded?". Wir machen uns deshalb aber gar keine Gedanken mehr den wir wissen das es normal ist und du ansich alles mögliche versuchen kannst, die Meldung wird nur mit Verzögerung auftauchen aber sie wird immer da sein.

NoLagg funktioniert man muss es nur richtig einstellen, d. h. alle Funktionieren durchlesen und ggf abschalten Ohne das konnten wird teilweise gar nicht mehr spielen weil mit jeder neuen MC Version die Performance vom Server aus schlechter wurde. Durch NoLagg werden alleine die Chunks anders gerendert was einen erheblichen Performance Boost gibt genauso wie die Lichtberechnung.

Hier mal unsere Config von NoLagg, ist aber allerding für Bukkit 1.4.6-R0.3 da ich zu faul bin zum Updaten und wird derzeit eh Tekkit Lite spielen

#> 
#> This is the configuration of NoLagg, in here you can enable or disable features as you please
#> For more information, you can visit the following websites:
#> http://dev.bukkit.org/server-mods/nolagg/
#> http://forums.bukkit.org/threads/nolagg.36986/

# Attempts to fix block and sky lighting bugs in worlds
lighting:
  # Whether Lighting should be loaded on startup
  enabled: true
  # Whether or not lighting is automatically fixed when a new chunk is generated
  auto: true

# Common features such as the clear and garbage collect commands
common:
  # Whether Common should be loaded on startup
  enabled: true
  
  # Several shortcuts you can use for the /nolagg clear(all) command
  clearShortcuts:
    enemies:
    - monster
    notneutral:
    - monster
    - item
    - tnt
    - egg
    - arrow
    all:
    - items
    - mobs
    - fallingblocks
    - tnt
    - xporb
    # The entity types removed when using /lag clear without arguments
    default:
    - items
    - tnt
    - xporb

# Notifies when a main-thread only event is called from another thread to detect instabilities it may cause
threadcheck:
  # Whether ThreadCheck should be loaded on startup
  enabled: true

# Manages chunk loading and sending to clients using various new settings, also fixes chunk unload problems
chunks:
  # Whether Chunks should be loaded on startup
  enabled: true
  # The minimum chunk sending rate (chunks/tick)
  minRate: 0.25
  # The maximum chunk sending rate (chunks/tick)
  maxRate: 1.5
  # If you use a plugin that depends on the net server handler for packets, disable this
  # For example, Raw Critics' Ore Obfuscation does not function with this enabled.
  # Orebfuscator is supported and works with this enabled.
  bufferedLoader:
    # Whether or not to use the buffered packet loader to reduce new memory allocation
    enabled: true
    # The amount of threads to use to compress the chunk packets (increase if it can't keep up)
    threadCount: 2
  # Sets whether the dynamic view distance should be enforced
  # If you use maxTPS, set this to false, or it will conflict!
  useDynamicView: true
  # Sets multiple view distances for different amounts of loaded chunks (chunk_count: view_chunks)
  # To disable, remove all chunk: view nodes. The view is smoothed out between nodes
  # The dynamic view distance will never be higher than the server view distance!
  dynamicView:
  - 0 = 13
  - 5000 = 13
  - 10000 = 13
  - 60000 = 13
  # Sets in what order chunks are sent to the client
  # Available modes: SLOPE and SPIRAL
  sendOrder: SLOPE

# Can examine server tick rate performance
examine:
  # Whether Examine should be loaded on startup
  enabled: true
  
  # The maximum time in ticks a generated examine report can be
  # It can be increased, but the generated file might be too large for the viewer to handle
  maxExamineTime: 72000

# Can monitor and log server and player performance statistics
monitor:
  # Whether Monitor should be loaded on startup
  enabled: true
  # The interval at which new performance snapshots are generated
  monitorInterval: 40
  # Whether or not to start logging server performance on startup
  startLoggingOnStartup: false
  
  # The server notifies players (with a permission) when the tick rate drops below the threshold
  lagNotifier:
    # Enable or disable this feature
    enabled: false
    # The interval in miliseconds to send this message (1000 ms = 1 second)
    interval: 10000
    # The tick rate at which it starts broadcasting
    threshold: 15.0
    # The message to send to these players
    message: &cThe server can't keep up!

# Buffers items in chunks to prevent lag-outs because of lots of items
itembuffer:
  # Whether ItemBuffer should be loaded on startup
  enabled: true
  # The maximum amount of items allowed per chunk
  maxItemsPerChunk: 80

# Stacks nearby items to counter item-drop spammers and reduce item count on the server
itemstacker:
  # Whether ItemStacker should be loaded on startup
  enabled: true
  # The block radius to look for other items when stacking
  # You can set it for multiple worlds
  radius:
    default: 1.0
  # The amount of (physical) items needed to form one stack
  threshold: 2
  # The interval in ticks at which item stacking is performed (1 tick = 1/20 sec)
  interval: 20
  
  # The item types (materials) to ignore during item stacking, buffering and spawn limits
  # Use 'orb' to ignore experience orbs
  ignoredItemTypes:
  - DIAMOND_PICKAXE
  - WOODEN_HOE

# Keeps entity counts below multiple configured thresholds
spawnlimiter:
  # Whether SpawnLimiter should be loaded on startup
  enabled: false

# Replaces explosion creation with a faster version and buffers TNT ignites to prevent TNT server crashes
tnt:
  # Whether TNT should be loaded on startup
  enabled: true
  # The interval (in ticks) at which TNT is detonated by explosions
  detonationInterval: 1
  # How many TNT is detonated by explosions per interval
  detonationRate: 10
  # The explosion crater size factor
  explosionRadiusFactor: 1.0
  # The amount of explosion packets to send to the clients per tick
  explosionRate: 5
  # If TNT explosions can change non-TNT blocks
  changeBlocks: true

# Alters the way worlds are saved to reduce disk usage and to force proper saves
saving:
  # Whether Saving should be loaded on startup
  enabled: true
  # The tick interval at which the server saves automatically (20 ticks = 1 second)
  autoSaveInterval: 400
  # The amount of chunks saved every tick when autosaving
  # If saving causes severe tick lag, lower it, if it takes too long, increase it
  autoSaveBatchSize: 20
  # Whether NoLagg will attempt to write all world data to the region files at a set interval
  # This is done on another thread, so don't worry about the main thread lagging while this happens
  writeDataEnabled: true
  # The tick interval at which the server actually writes the chunk data to file (20 ticks = 1 second)
  writeDataInterval: 12000

# Notifies the current stack trace of the main thread when the server freezes
threadlocknotifier:
  # Whether ThreadLockNotifier should be loaded on startup
  enabled: true

 

[mr.madman]

Ganz dickes Danke.

Dann wird NoLagg nochmal ausgegraben - deine Config kann ich ja schon mal als Basis nehmen

Werde ich mich die Tage gleich mal dranmachen und einlesen - je nachdem, wie es die Arbeit zulässt.

Das mit dem Multithreading hat mich von daher überrascht, dass meine Info bisher exakt eben auch die war, dass bukkit auf nur einem Kern läuft - daher hat der vorherige Server auch nen Core Solo bekommen. Es geistert halt hier und da mal so Halbwissen rum, dass seit geraumer Zeit, wenigstens die Chunks in einem separaten Thread abgehandelt werden.
Wenn ich Bukkit auf beiden Kernen lasse, läufts halt gut, mit sporadischem "Can't keep up". Wenn ich im Taskmanager Bukkit auf einen Kern lege - egal ob nun der 1te oder 2te - läuft die Konsole förmlich über vor den besagten Errors.

Werde das nochmal genauer testen, vielleicht spielt da noch was Anderes mit rein und schauen ob ich das Board auf einen FSB jenseits der 400 bekomme, dann wird der sparsame Celeron 420 wieder interessant

 

[clrokr]

gestartet wird der Bukkit mit

java -Xms512M -Xmx1536M -jar craftbukkit.jar

Das Maximum für 32bit Java unter Windows soll ja bei 1792M liegen.

sobald ich den xmx auch nur um 1MB über die 1536M erhöhe bekomme ich folgendes:

Error occurred during initialization ov VM
Could not reserve enough space for object heap
Could not create the Java Virtual Machine

... und das obwohl genug RAM da ist und unter 32bit XP ja 2048MB pro Thread möglich sind

Java (zumindest die 32-Bit JRE) kann nicht mehr als 1536MB für den Heap benutzen:
Dokumentation vom IBM

Mit einer 64-Bit Variante könntest du mehr Glück haben, aber da musst du dann tatsächlich auf ein 64-Bit Windows umstellen.

Clemens
http://www-01.ibm.com/support/docview.wss?uid=swg21249894