Server Ressourcen

[Pius Noel]

Edit: Hast du mal versucht die Größe des Threadpools zu vergrößern? Ich denke an "MaxPoolThreads" aus der OpenSim.ini. Das behebt zwar nicht den Engpass selber, aber verhindert, dass infolgedessen die verfügbaren Threads ausgehen.

Boah... nein, das hatte ich nicht versucht
In der Regel konnte ich einen oder 2 Kerne beobachten die mehr CPU-Zeit (bein Starten gegen 100%) brauchten. Das waren auch nicht immer die gleichen, sie wechselten sich ab. Die übrigen Kerne zeigten ein ausgewogenes Bild. Aber klar, wenn ich sie nicht nutze, dann bringen sie auch nichts.

Es geht mir wie dir, ich habe die Threads und das Verhalten nie ganz verstanden und bin mit den Resourcen in dieser Hinsicht eher konservativ umgegangen, da ich immer wieder Crashes erlebt habe, wenn ich höhere Werte verwendet habe.

[Bogus Curry]

Hallo zusammen ;D

Hat jemand schon mal OpenSim auf Docker laufen lassen. Ich hab ein Projekt gefunden, wo jemand OpenSim auf Docker als Image erstellt hat. Hab bisher nicht getestet, kann mir aber vorstellen das die Performance nicht so schlecht sein kann.

Hier mal den Link ..
https://github.com/QuantumObject/docker-opensimulator

[Mareta Dagostino]

Selber habe ich keine Verwendung (mehr). Seit Hetzner preiswerte VMs in ihrer Cloud anbieten, die man stundenweise bezahlen und wieder kündigen kann, bin ich froh, mich nicht mehr um einen eigenen Host kümmern zu müssen.

Es gibt aber keinen technischen Grund, der gegen Docker spricht. OpenSim ist ein klassisches Anwenderprogramm mit sehr bekannten Schnittstellen zum System (.NET bzw. Mono), arbeitet mit dem gängigsten Internetprotokoll ever (TCP/UDP IP), benötigt nirgendwo Adminrechte oder direkten Systemzugriff. Würde sowas in Docker Probleme machen, dann wäre Docker Schrott ... was es ja bekanntlich nicht ist.

Liebe Grüße und viel Spaß mit Docker,
Mareta

[Mareta Dagostino]

EDIT: Akira betreibt ihre Regionen in Dereos allesamt als Docker-Images.

[Jules Dreki]

...
Allerdings haben wir bei der Geometrie des Grids einen ganz anderen Weg gewählt. Wir haben uns für 2x2 Var Regionen entschieden, zur Zeit 21 davon für das Kerngebiet des Segelreviers.
...

Hallo Zusammen,

ich bin leider noch nicht mit meinen Tests fertig. Die wichtigste Änderung ist, das ich die Region nicht mehr irgendwo andocke sondern im Grid-Mode rein lokal betreibe, um den Upload als Flaschenhals zu umgehen. Die Ergebnisse liefere ich in den nächsten Tagen nach.

An Christoph habe ich aber eine Frage. Die Wahl von var2x2 hört sich soweit logisch an. Auch wenn ihr, wie Du selbst schreibst, mit den Simübergängen nicht wirklich zufrieden seid. Aus meiner SL-Erfahrung heraus, war das eben der Grund für eine grosse Var-Region ohne Sim-Übergänge.

Ok, meine Frage: Ich habe gehört, dass die Entwicklung von den Opensims und SL zum Teil auseinandergelaufen sind. Ist das Andocken von Regionen in SL etwas Normales. Soll es so sein, das in den Opensims 2 benachbarte Regionen sich hinsichtlich der Performance gegenseitig negativ beeinflussen. Man es also eigentlich tunlichst unterlassen soll, in den Opensims Regionen aneinander anzudocken. Wie passt dass denn nun zusammen? Sorry, in dem Punkt verfüge ich leider über keine eigenen Erfahrungen.

[Jules Dreki]

Hier doch schon mal das Ergebnis für ein var16x16. Es ist zwar etwas im Telegrammstil geschrieben, aber ich denke dennoch aussagefähig:

1. var16x16
============
Rechner: 10 Cores; 64GB RAM
Viewer: Firestorm 6.0.2.56680
Viewer: Singularity 1.8.9 (8324)

Die Viewer unterschieden sich nicht signifikant.
Rein lokaler Test um Upload als Flaschenhals zu umgehen.

Standalone
-----------
--> der komplette Simulator läuft auf einem Prozessor
leere Region und Avatar fliegt --> CPU Auslastung >> 100%

PS: Zu der Zeit als ich den Standalone Mode testete, kannte ich noch nicht die Möglichkeit den Programmen definierte CPUs zuweisen zu können. Es war also die Standardeinstellung und so das Programm für alle Cores freigegeben. Daher wurden sicher mehr als ein Core benutzt, aber mindestens ein Core war zu 100% ausgelastet.

Grid Mode mit MariaDB
---------------------------

==> Unterteilung in mehrere Prozesse auf eigenen Cores.

1xCore MariaDB
1xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm (sehr schnell auf 100% --> 3Core)

In der Konfiguration upload der OARs. Nach Neustart der kompletten Umgebung:
4x4 OARs = 16 Parzellen (16x16 = 256 Parzellen; Faktor 16)
110.000 Prims
4800 Skripte
12GB RAM --> 16x12GB = 192GB (hochgerechnet)
In Ruhe 50-55% Core Auslastung
Avatar fliegt 60% Core Auslastung

--> 1xCore MariaDB --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Opensim.exe --> kleine Auslastung (schlecht abzulesen)
--> 1xCore Robust.exe --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Firestorm
==> CPU_ges. 80% und RAM Verbrauch durch Simulator und Datenbank kein Flaschenhals

Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess
der mindestens kurzzeitig einen Core zu 100% auslastete.

Ergebnis:
Hin- und herlaufen kein Problem. Teleportieren kein Problem. Fliegen mit dem Avatar geht auch, allerdings mit kurzen Aussetzern. Also nicht wirklich flüssig, und das bereits ohne ein Auto oder Flugzeug. Daran änderte sich auch nichts entscheidend als für alle Programme alle Prozessoren wieder zugelassen wurden. Der Simulator lastete die Hardware bei Zuweisung genügender Ressourcen diese nicht aus, war aber mit z.B. einer Gesamtauslastung der CPU mit 80% schon recht hoch. Der Viewer geriet dagegen immer wieder kurzzeitig an seine Grenzen.

Vermutlich liegt es an der grundsätzlichen Implementierung der Viewer. Starte ich ein modernes 3D Spiel wird der PC insgesamt lauter, was vorallem an den hochdrehenden Ventilatoren der Grafikkarte liegt. Er pustet dann vernehmlich. Das blieb in der Testumgebung aus. Daher meine Vermutung, daß der Viewer noch vieles selbst mit der CPU berechnet, und weniger Aufgaben als ein modernes Spiel an die Grafikkarte zur Berechnung übergibt.

Fazit:
Ein var16x16 macht für eine Flugplatz Region nicht wirklich Spass.
Es wird ein weiterer Versuch mit einer var8x8 durchgeführt.
Später wäre auch ein Test mit aus kleineren Regionen zusammengesetzter grösseren Map denkbar.

[Jules Dreki]

Noch ein Tip: Bei den Tests hat mich am Anfang beim Fliegen ein Flackern zwischen Terrain und Wasser gestört. Ganz habe ich es nicht beseitigen können, aber ich konnte es stark minimieren:

Menü->Viewer Einstellungen->Grafik->Allgemein: Erw. Beleuchtungsmodel auswählen.
Menü->Entwickler->Rendering: Objekt-Objekt Occlusion deaktivieren.

[Christoph Balhaus]

Hallo Jules,

ja die Simübergänge sind gefühlt etwa so wie in der Blake Sea in SL an einem guten Tag. Also Segeln ist schon ganz OK, nur für schnellere Fahrzeuge nicht wirklich zufriedenstellend. Immerhin haben sich durch die 2x2 Vars auch die Anzahl der Simübergänge gegenüber Standardsims schon halbiert und diese gelegentlich extrem langen Aussetzer wie in SL oder gar Crashes sind sehr selten.

Einen negativen Effekt beim zusammenfügen von Regionen habe ich bislang nicht gesehen, kann ich also nicht bestätigen. Natürlich muss der Viewer dann deutlich mehr Objekte darstellen als bei einer einzelnen isolierten Region, aber den Effekt hättest du auch wenn sich alles auf einer einzelnen grossen Region befindet. Serverseitig sehe ich da keine signifikanten Effekte.

Allerdings sieht jedes Grid anders aus: Unseres läuft auf eigenem Blech mit weniger Cores als du sie benutzt, die dafür aber schneller als auf einem typischen VPS sind und seltener die Leistung einzelner Threads begrenzen. Dann ist die Gesamtauslastung auch mit den 21 Vars plus unseren Sandboxen und anderen Projekten immer noch sehr gering und die Bebauung hat auch eher die Blake Sea als Vorbild, also viel Wasser zum Segeln mit einzelnen Inseln und Objekten dazwischen und nur wenigen grösseren zusammenhängenden Gebieten. Ich erwarte Probleme weniger von den Objekten als eher durch die Scripte.

Die Performance wird aber noch ein spannendes Thema werden wenn es ersteinmal stärker belastet wird. Ich würde gerne etwas genauer messen können wo es dann genau hängt, einerseits bei den Simübergängen, andererseits generell bei hoher Auslastung.

Deine Beobachtung mit der CPU-lastigkeit des Viewers kenne ich auch. Das hat viele Gründe. Die Levels in Spielen werden von Profis gemacht, sind weitgehend statisch und können deswegen hoch optimiert werden. So ein SL-Viewer muss da sehr viel schwerer verdaulichen Content darstellen und stammt zudem noch aus einer Zeit, wo Multithreading kein grosses Thema war.

Auch das mit der Ambiant Occlusion kann ich bestätigen. Da die AO in erster Näherung ohnehin nur gering von der Beleuchtung abhängt, backen wir die eher in die Texturen ein und lassen es im Viewer immer ausgeschaltet.

/Chris

P.S.: was für einen Effekt versprichst du dir von dem CPU Pinning?

[Jules Dreki]

Hi Christoph,

Mit CPU-Pinning meintest Du sicher das gezielte Zuordnen der Programme zu bestimmten Cores. Das diente nur dazu dass ich wusste auf welchen Cores welches Programm läuft, und ich so die Core Auslastung bezogen auf die Programme beurteilen konnte.

Dabei bin ich so vorgegangen, daß zunächst jedes Programm nur einen Core bekam. Ging der in die Auslastung gab es einen zusätzlichen Core bis nicht alle dem Programm zugeordneten Cores in die 100%ige Auslastung gingen. Am Ende gab ich dann wieder alle Cores für alle Programme frei, was der Standardeinstellung unter Windows 10 entspricht, dabei haben sich die Reaktionen im Viewer nicht signifikant verändert. Die gewählte Anzahl der Cores pro Programm muss also ausreichend gewesen sein, und so die Belastung der Cores real wiedergespiegelt haben.

Durch diese Vorgehensweise bin ich dann ja auch erst auf den Viewer als Core-lastigen Flaschenhals gestoßen.

[Jules Dreki]

2. var8x8
============

Rechner: 10 Cores mit 20 logischen Prozessoren; 64GB RAM
Viewer: Firestorm 6.0.2.56680
Viewer: Singularity 1.8.9 (8324)

Die Viewer unterschieden sich nicht signifikant.
Rein lokaler Test um Upload als Flaschenhals zu umgehen.

Aufgrund der Testergebnisse mit der Var16x16 wird auf einen Test im Standalonemode verzichtet.

Grid Mode mit MariaDB
----------------------

1xCore MariaDB
3xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm

4x4 OARs = 16 Parzellen (8x8 = 64 Parzellen; Faktor 4)
110.000 Prims
4800 Skripte
11GB RAM --> 4x11GB = 44GB (hochgerechnet)
In Ruhe 50% CPU Auslastung
Avatar fliegt 50% CPU Auslastung
==> CPU_ges. 80%

Ergebnis:
Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess der mindestens kurzzeitig einen Core zu 100% auslastete. Das Ergebnis unterscheidet sich zunächst also nicht sehr von dem var16x16 Test. Leichtes Ruckeln wenn der Ava fliegt.

Wenn man aber für den Firestorm zur Windows Standardeinstellung zurückkehrt, das heisst, der Viewer ist für alle Cores freigegeben. Gibt es keinen Core mehr der zu 100% ausgelastet ist. Es ist nach wie vor eine hohe Auslastung aber keine 100%ige. Dieser kleine Unterschied bewirkt das man mit einer Sichtweite von 256m mit dem Avatar flüssig fliegen kann. Wahrscheinlich fällt mein Ergebnis im Gegensatz zu Pius seinem Test nicht so deutlich aus, da ich nicht auf einem Server sondern auf meinen Lokalen PC testete, und da lief noch etwas mehr als der Opensimulatortest.

Fazit:
Auf einen echten Server sollte der Opensimulator mit einer var8x8 problemlos laufen. Vor allem wenn dann der Viewer abgesehen von den ganzen Hintergrundprogrammen die einzigste Anwendung auf dem PC ist. Eine var8x8 sollte also bei sparsamer Bebauung, Zurückhaltung bei den Skripten und einer Sichtweite von 256m schon Spass machen.

Die Frage, die es noch zu klären gilt, ist, lässt sich die Belastung des Viewers verringern, in dem die Map in Teile zerlegt wird? Bringt es also etwas, dem Beispiel Christophs mit seiner Segelregion zu folgen, und kleinere Regionen zu einer Grösseren aneinanderzudocken?