Informationen und Bekanntmachungen

Kommentare, Fragen und Vorschläge zu dem Devblog Building a Balanced Universe sind hier herzlich willkommen.

CCP PrismX beschreibt in dem Blog die Überarbeitung des Cluster-Loadbalancers, der dafür sorgen soll, dass die Last des Tranquility-Clusters möglichst gleichmäßig auf die vorhandenen CPU-Kerne verteilt wird und die Mechanik des Time Dilation (TiDi) nur in Ausnahmefällen (automatisch) einsetzt.

Ein Loadbalancer ist deswegen notwendig, da deutlich mehr Sternensysteme und anderweite Dienste existieren als CPU-Kerne im Tranquility-Cluster. Deswegen müssen mehrere Systeme jeweils auf einen CPU-Kern gelegt werden. Diese Belegung soll natürlich optimal sein, sodass alle CPU-Kerne möglichst gleichmäßig belastet sind. Da einige Systeme deutlich stärker belastet sind als andere Systeme (man denke nur an beliebte Systeme für Missionen und nahezu ausgestorbene Lowsec-Systeme), kann man nicht einfach die CPU-Kerne mit einer konstanten Menge an Systemen belegen. Zudem ändert sich die Belastung der einzelnen Systeme, sodass ingesamt ein Loadbalancer notwendig wird, der in jeder Downtime die Belegung der CPU-Kerne mit Systemen neu berechnet.

In der Vergangenheit wurden Systeme in einer Constellation möglichst auf denselben CPU-Kern (auch als Node bekannt) gelegt, aus Gründen die inzwischen widerlegt sind. Ebenso haben wir seit dem Sommer feststellen müssen, dass auch Systemen, deren Last gut vorhersehbar ist, oftmals TiDi eingesetzt wurde. Zudem verteilte der Loadbalancer auch weit entfernte Systeme auf denselben CPU-Kern, sodass TiDi oftmals unvorhergesehen und scheinbar mysteriös "aus dem Nichts" in Systemen niedriger Last einsetzte (weil andere, hochbelastete, aber weit entfernte Systeme auf demselben CPU-Kern liefen).

Der Loadbalancer wurde daher neu geschrieben (in Phython und nicht mehr SQL) und verbessert. Der Balancer basiert auf einer rekursiven Bisektion und erzeugt zusammenhängende Graphen. Es wird also nicht mehr weit entfernte Systeme geben, die auf demselben CPU-Kern laufen. Nullsec- und Empire-Gebiet werden hierbei in getrennten Abläufen ausbalanciert und hängen nicht miteinander zusammen.

Der neue Loadbalancer wird ab dem 4. Dezember 2013 eingesetzt. Der Originalblog enthält weitere Informationen und Diagramme.

Du kannst vor der Downtime als CEO eine Node reinforcement beantragen. Das wird dann automatisch bearbeitet.

Live ohne downtime ein system auf ein anderen Node zu verschieben geht noch nicht so gut. Die arbeiten aber drann.

Das gibt bisher noch Probleme, da der Node ja noch Verknüpfungen zu Datenbankservern usw. hat.

Du müsstest dann allen anderen Servern mitteilen, wohin der Node verlegt wird und eine Lösung für die Übergangsphase finden. Auch weiß ich nicht, ob du diese neue Zuordnung nicht sogar für jeden Spieler und jedes Objekt machen müsstest. Das wäre dann eine riesen Aufwand.

Zumindest wird ein Live Switch nicht einfach zu regeln sein und eventuell mit dem aktuellen Aufbau des Serverclusters gar nicht machbar sein.

Ist halt grade bei big Fights im 0.0 stöhrend, aber ich verstehe schon, das es nicht grade einfach ist ein sys sofort oder auch nur halbwegs zeitnahe von 200 leute auf 4000 hochzufahren. Allerdings werden auch die flotten eher größer als kleiner.
Diese problematik wird also in Zukunft mehr.

Ich denke mal, das es veiele von euch selber schon miterlebt haben.... solche Fights sind die reinste Zeitlupenstudie... ja, es ist besser als die Lags von früher. viel besser, aber noch ist es nicht gut.

Vielleicht läst sich mit dem wechsel von SQL auf Phython ja etwas verbessern. Ich kans nur hoffen und jeder FC wohl auch.

Auf welcher Basis geschieht dann die Festlegung. Sicher wenn man die Aktivitäten der letzten 24 Stunden heranzieht kann man eine grobe Verteilung machen. Aber gerade bei großen spontanen Fights wird halt dann eine Drama.

Na aber jetzt mal eine andere Idee die mir gerade so durch den Kopf geistert....


Die Systeme die jetzt ne hohe Auslastung haben... (Jita und die anderen Hubs und allgemeine Ballungszentren sind den Admins ja eig. bekannt) könnten doch (wenn das funzt) seperat auf einer wesentlich stärkeren Resource laufen.....zwar meine i9ch das so das solche temporären Belastungen sich überhaupt nicht auf die restliche Spielwelt auswirken

Nur mal so als Beispiel damals bei Battlefield....man konnte diversen Servern die Prozessoren zuweisen (wenn man mehrere Server hatte)


Wäre sowas nicht auch realisierbar in EVE?Also hohe Belastung einer Region...gleich mehr Resis verteilen das es überhaupt nicht zu eigentlich "vorhersehbaren Schwulitäten" kommt?

Jita läuft schon auf einem eigenen Node, soweit ich das weiß. Leider kann ein System nicht zwei Nodes zugewiesen werden .-)

Nach welchen Faktoren wird den in der DT die System auf die CPUs verteil ?
Wird da die Aktivität der letzten 48 Stunden hergenommen und an Hand dieser dann die Ressourcen vergeben ?

Der GIL hört sich interessant an.
Das heißt das der Limitierende Faktor, in Wirklichkeit nicht unbedingt die Hardware ist, sonst Python.

Gibt's hier schon einen Plan seitens CCP auf eine andere Programmiersprache umzusteigen ?
Oder andere Lösungswege, wie zum Beispiele eine Vitalisierung der Hardware, die dann mehrere CPU Kerne zu einem zusammen fasst. Vorausgesetzt das geht mit Python, und treibt die Programmierer nicht in den Wahnsinn.

Wenn ich das richtig verstehe kann mit diesem System in der Downtime also nur eine theoretische Balance gestellt werden.
Bei 0.0 Kämpfen die nicht angemeldet werden oder besser werden können aufgrund spielertechnischer Fehler die ausarten wie in Asakai, wird der Node, wie jetzt auch, immer wieder ausfallen oder 5-10% Tidi sein... wie jetzt auch.
Es ändert sich nichts relevantes außer, dass wenn jetzt Tidi auftritt man weis, seine Nachbarsysteme sind direkt betroffen.
Ergo es ändert sich nur die Sprache aber nicht das grundlegende Problem das das System zu statisch ist bzw nicht Flexibel genug.

Und da sich neuer Code nicht von heute auf morgen schreibt und debugged, wird des noch dauern.

Ein hoch auf die Programmierer.
Ich bin schon beim Schiffversenken gescheitert mit C#