Server laggt extrem bei Droppartys

[HardcorePvP]

Hallo,
unser Server läuft normalerweise sehr Stabil bei bis zu 100 Spielern. Er läuft auf nem root mit 24 GB RAM und einem i7-3770. Auch vor den Events mit über 100 Spielern sind auch noch keine starken Laggs festzustellen. Jetzt zum Problem:
Sobald alle Spieler am Spawn versammelt sind und man anfängt, Items zu droppen, explodiert die CPU und RAM auslastung und der Server laggt extrem und beim Einloggen bekommt man meist timeouts.
Wir hatten ursprünglich einen i7-950 und haben dann aufgestockt. Wirklich besser war es nicht. Woran liegt das und was kann man da tun um das nächste Event nicht zu vermasseln?

Bitte nur Antworten wenn Du auch Ahnung hast und wirklich einen Lösungsvorschlag hast.

LG,
bloodi

 

[LordKaktus]

Vermutlich keine völlig hirnverbrannten events schmeißen, bei dem man hunderte oder tausende von Entitys erzeugt, die allesamt mehrmals pro sekunde berechnet werden müssen und somit ungemein den Prozessor belasten.

Spigot fasst nicht umsonst herumliegende items zusammen.

Auch "Anti-Lag-Plugins" vernichten nicht ohne Grund in regelmäßigen Abständen alle herumliegenden items.

 

[HardcorePvP]

Bitte nur Antworten wenn Du auch Ahnung hast und wirklich einen Lösungsvorschlag hast.

"Hirnverbrannt" und "tausende Entitys" ist eventuell ein wenig übertrieben.
Und Items, die sofort wieder aufgehoben werden, sind glaub ich keine große Belastung.

 

[Inkemann]

"Hirnverbrannt" und "tausende Entitys" ist eventuell ein wenig übertrieben.
Und Items, die sofort wieder aufgehoben werden, sind glaub ich keine große Belastung.

Glaubst du? Wenn es nicht irgendein Plugin bei dir gibt, dass für jedes Item droppen bzw. aufheben irgendetwas macht, dann liegt es einfach an der Menge der Entities. Also nach und nach alle Plugin testen.

 

[BlueFreakLP]

4x 3,4Ghz sind durchaus schwach für die Anzahl an Entitys. Ich finde die CPU ist viel zu schwach dafür, man dürfte darauf maximal einen Minecraft Server mit 16GB Ram betreiben. 100 Spieler ist eine mächtige Anzahl und wie bereits die vorrender sagten, 100 Spieler jede Sekunde prüfen ob ein Entity in der nähe liegt, welches aufgehoben werden kann....
Außerdem ist die Frage kommen bei euch SSDs oder HDDs in einsatz? Ich würde die IO Performance mal überwachen in wie fern die Festplatten ausgelastet sind.

Aber wie bereits gesagt, die Hardware ist recht schwach, scheint wohl ein RootServer zu sein von einem Preiswerten Anbieter.

 

[WolfezzBlazer]

Nicht mehr RAM nutzen, als benötigt, Timings wären auch praktisch (/timings on -> 5-15min warten -> /timings paste -> Link schicken)
Nicht mehr RAM, da der GC (Garbage Collector) den ganzen RAM durchgehen muss, also auch den ungenutzen, dass kostet CPU und produziert laggs^^

 

[Mario52]

Wir haben SSDs auf dem Server. Das mit dem RAM könnten wir auch mal versuchen.

 

[Inkemann]

Nicht mehr RAM nutzen, als benötigt, Timings wären auch praktisch (/timings on -> 5-15min warten -> /timings paste -> Link schicken)
Nicht mehr RAM, da der GC (Garbage Collector) den ganzen RAM durchgehen muss, also auch den ungenutzen, dass kostet CPU und produziert laggs^^

Nein, nein, nein! Das ist völliger Unsinn! Die Garbage Collection läuft am besten, wenn mindestens 5 mal so viel freier Speicher wie genutzter Speicher zur Verfügung stehen. Also bloß nicht noch RAM wegnehmen, dass macht es langsamer und nicht schneller!

 

[HardcorePvP]

Wir können den RAM auch nicht beeinflussen, da McMyAdmin den RAM zuweist. Als max. RAM haben wir somit 24 gb eingestellt.

Eine weitere seltsame sache: Die TPS waren meistens sehr hoch, trotz starker laggs.
An der Bandbreite kann es eigentlich auch nicht liegen. Hetzner hat eine gute Anbindung, der Speedtest zeigt ca. 400 mb/s download und 100 mb/s upload.

Aber wie bereits gesagt, die Hardware ist recht schwach, scheint wohl ein RootServer zu sein von einem Preiswerten Anbieter.

Er kostet jetzt schon über 60 Euro im Monat. Roots mit wirklich guten CPU's lägen dann im 3-stelligen Bereich, was wir/unser Sponsor sich nicht leisten kann.

 

[meytro]

Nein, nein, nein! Das ist völliger Unsinn! Die Garbage Collection läuft am besten, wenn mindestens 5 mal so viel freier Speicher wie genutzter Speicher zur Verfügung stehen. Also bloß nicht noch RAM wegnehmen, dass macht es langsamer und nicht schneller!

Was für ein Schwachsinn.

Wenn du mal ein Timing liefern würdest könnte man dir helfen aber das scheinst du ja gekönnt zu ignorieren

 

[Inkemann]

Was für ein Schwachsinn.

Ich zitiere aus dem Paper "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" von Matthew Hertz und Emery Berger:

„In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower.“

Mit fünf mal soviel Speicher wie benötigt, erreicht Garbage Collection (sehr ähnlich wie sie in der Java VM implementiert ist) die gleiche oder eine bessere Laufzeit wie explizite Speicherzuweisung. Darunter fällt GC sehr schnell ab.

Zurück zum Thema: Ich würde mal mit wenig Plugins testen und dann nach und nach welche dazuschalten. Ich wette es ist irgendein Plugin, das für alle Items ein Event nutzt und damit die CPU-Last nach oben treibt.

 

[montbit]

Eine weitere seltsame sache: Die TPS waren meistens sehr hoch, trotz starker laggs.

Auch Dein Rechner hat viel Arbeit bei so vielen Spielern und dann noch die massenhaften Items. Schon daran gedacht?

 

[HardcorePvP]

Man kann nicht mal eben in einem Event mit 100 Spielern die Hälfte der Plugins deaktivieren und am Besten zwischendurch noch 10 mal neustarten. Wir werden in Zukunft einfach auf Droppartys verzichten müssen

 

[Inkemann]

Man kann mal eben mit etwas weniger Spielern testen, auf einem anderen Server.

 

[meytro]

Oder ihr macht einfach mal ein Timings Report *gg*

 

[McLive]

Das gleiche "Problem" haben wir bei großen Dropevents auch. Zusätzlich schießt neben der CPU auch noch die Netzwerk-Auslastung mit Peaks von 80-90 Mbit/s in die Höhe.
Ich bin mir sicher, dass dies an den ganzen Entities liegt.

 

[meytro]

Das gleiche "Problem" haben wir bei großen Dropevents auch. Zusätzlich schießt neben der CPU auch noch die Netzwerk-Auslastung mit Peaks von 80-90 Mbit/s in die Höhe.
Ich bin mir sicher, dass dies an den ganzen Entities liegt.

Entitys verbrauchen keine Bandbreite sondern Chunks. Das liegt wohl dann daran dass sich viele Spieler an eine für sie neue Stelle bewegen und andere Chunks brauchen, während die meisten normalerweise in den gleichen Chunks mit einzelnen Block Updates leben.

 

[Inkemann]

Entitys verbrauchen keine Bandbreite sondern Chunks. Das liegt wohl dann daran dass sich viele Spieler an eine für sie neue Stelle bewegen und andere Chunks brauchen, während die meisten normalerweise in den gleichen Chunks mit einzelnen Block Updates leben.

Warum sollten sich viele Spieler in neue Chunks begeben, bei einem Event, das an einer fixen Stelle stattfindet? Natürlich erzeugen Entities auch Last, was glaubst du wie die Informationen über die Entities zum Client gelangen?

 

[HardcorePvP]

Das gleiche "Problem" haben wir bei großen Dropevents auch. Zusätzlich schießt neben der CPU auch noch die Netzwerk-Auslastung mit Peaks von 80-90 Mbit/s in die Höhe.

Endlich mal jemand der wirklich über seine Erfahrungen spricht. Danke dafür. Mich würde noch interessieren, wie viele Spieler auf was für einem Server es waren und wie ihr die Bandbreiten-Auslastung gemessen habt

 

[meytro]

Warum sollten sich viele Spieler in neue Chunks begeben, bei einem Event, das an einer fixen Stelle stattfindet? Natürlich erzeugen Entities auch Last, was glaubst du wie die Informationen über die Entities zum Client gelangen?

Nur um das klar zu stellen ich rede nicht davon dass neue Chunks generiert werden müssen. Ich meine dass die Netzwerkauslastung dann erzeugt wird wenn sich viele von irgendwo auf dem Server zum Event hinporten.

Ein Entity braucht im Verhältnis zu Chunks von denen jetzt nach Einstellung 25 bis 961 versendet werden so gut wie keine Bandbreite.

CPU Auslastung = Entitys
Netzwerk Auslastung = Chunks die an den Clienten gesendet werden