Server Ressourcen

[Jules Dreki]

Gleich an erster Stelle ein dickes Dankeschön an Copper Tomsen und Eryn Galen vom Metropolis-Grid die mich mit dem Folgenden sehr unterstützt haben.

Mir schwebt als eigene Region eine Flug-Sim vor. Es soll eine performante Region sein, und genügend Platz zum Fliegen bieten. Da das Thema neu für mich ist, war ich mir völlig im Unklaren, was für einen Server ich benötigen würde.

Von Manfred Aabye kam eine erste Abschätzung was man für so eine Sim minimal benötigen würde:
V-Server mit 8Cores und 30GB RAM für eine var16x16 = 4096m x 4096m

Eine var16x16 oder var8x8 erschien mir aber für einen lokalen Test als überdimensioniert, und ich entschied mich diesen mit einer var4x4 durchzuführen. Zunächst musste aber erst die Hürde der Installation der Metropolis-Edition des OpenSimulator und die Nutzung der 64Bit Variante gemeistert werden.

Im MetroWiki gibt es eine Anleitung zur Installation des OpenSimulator, also ging ich frisch und optimistisch ans Werk. https://hypergrid.org/metropolis/wiki/de...?title=SIM

Der Download und das Entpacken der Metropolis-Edition des OpenSimulator war schnell erledigt. Das .NET-Framework in der Version 4.8 war unter Windows 10 bereits installiert, und durch die Verwendung der Metropolis-Edition musste ich mich um das Thema dynDNS nicht kümmern. Wie sich später zeigte war auch das Thema NAT-Loopback mit der Fritz!Box 6490 Cable kein Problem.

Entsprechend der Anleitung und Lenas Beitrag zur neuen Metro gab ich in der Fritzbox die folgenden Ports frei. Ausserdem sorgte ich dafür das der lokale Firewall kein Hindernis für die opensim32.exe und opensim.exe sein würde. https://forum.metrogrid.de/discussion/50...neue-metro

TCP: 80
UDP+TCP: 9000
UDP+TCP: 9051

Dann suchte ich mir mit Hilfe des Dashboards noch freie Koordinaten. Da meine lokale Region nicht ständig online sein würde, wählte ich Koordinaten weit ab der 7000,7000. Damit war der letzte Schritt der Vorbereitung problemlos abgeschlossen, und die Installation selbst erforderte nur das Entpacken der Metropolis-Edition. SQLite sollte als Datenbank beibehalten werden also blieb die Datei ./opensim/bin/config-include/GridCommon.ini unverändert. Gestützt auf die Anleitung und der Beispieldatei Regions.ini.example ertstellte ich nur eine regions.ini für meine Region:

[Midgard]
RegionUUID = XXXXXXXXXXXX

Location = 490,500
InternalAddress = 0.0.0.0
InternalPort = 9051
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP

SizeX = 1024
SizeY = 1024
SizeZ = 1024

NonPhysicalPrimMax = 256
PhysicalPrimMax = 64
ClampPrimSize = False
MaxPrims = 250000
MaxAgents = 100

Als Erstes startete ich dann die opensim32.exe. Der Simulator lief fehlerlos hoch, und Coppers und mein Avatar konnten die Region betreten. Bingo, das war ermutigend. Von der folgenden Seite besorgte ich etliche 256mx256m grosse OARs von Linda Kelly die auf die Region geladen werden sollten.

https://zadaroo.com/oars/

Das ging allerdings quälend langsam, und das permanente Abspeichern schien nicht zu funktionieren. Wie ich aber jetzt von Eryn weiss, gelangen die OAR-Daten zunächst nur in den Cache, und man muss mit dem Befehl "backup" für eine Übertragung in die Datenbank sorgen. Was auch wieder quälend langsam ging.

Neustart der Region nach OAR Upload/Bauen:
1. "backup"
2. "shutdown"
@Eryn: Ich habe das unter Missachtung aller Pausen direkt hintereinander ausgeführt, sobald der Prompt wieder erschien. Trotz aller gegenteiliger Erwartungen funktionierte das.

Da nun die 32Bit Version des OpenSimulators nur mit 4GB RAM (2^32=42949672996) umgehen kann, und die Datenbank SQLite deutlich langsamer als MySQL/MariaDB ist. Sollte nun, auf Eryns Rat hin, der Wechsel zum 64Bit Opensimulator und der Datenbank MariaDB erfolgen.

https://mariadb.org/download/

Zum Wechsel zur 64Bit Variante des Opensimulators muss man statt der opensim32.exe einfach nur die opensim.exe starten. Aber genau das funktionierte nicht ohne Fehlermeldung.

(ERROR - OpenSim.Framework.Servers.HttpServer.BaseHttpServer
[BASE HTTP SERVER]: HandleRequest() threw exception System.FormatException: Die Eingabezeichenfolge hat das falsche Format)

Die Lösung war zum Glück im Metro-Forum zu finden. Pius Noels erster Beitrag im 4.Absatz unter dem folgenden Link: https://forum.metrogrid.de/discussion/co...ment_33408

Also fügte ich in der Datei ./bin/OpenSim.exe.config den folgenden Eintrag im Abschnitt <runtime> hinzu.
<useLegacyJit enabled="1" />

Danach erfolgte die Installation der MariaDB Datenbank. Unter Windows startet man dafür einfach nur das Setup-Programm. Ich habe darauf geachtet das Root-Zugriffe nur lokal erfolgen dürfen und die Datenbank für die Verwendung des UTF8 Zeichensatzes eingerichtet wird. Für die Konfiguration der Datenbank bin ich der Anleitung Maretas gefolgt.

https://hyperweb.eu/server/ubuntu1804/mysql/

Dabei gleich ein Tip, wählt für den user der opensim Datenbank ein Passwort ohne Sonderzeichen. Ihr werdet gleich sehen warum. Nachdem die neue Datenbank lief musste nun der Opensimulator entsprechend der Anleitung im MetroWiki noch auf diese Datenbank umkonfiguriert werden.

https://hypergrid.org/metropolis/wiki/de...figuration

Dabei muss die Zeile für die SQLite Datenbank auskommentiert und die folgenden Zeilen für MySQL aktiviert werden.
StorageProvider = "OpenSim.Data.MySQL.dll"
ConnectionString = "Data Source=localhost;Database=Opensim;User ID=Opensim Password=****;Old Guids=true;"

Wenn ihr Euch jetzt den ConnectionString anschaut müsste klar werden, warum Passwörter mit Sonderzeichen speziell mit Anführungszeichen nicht funktionieren können. :-) Anführungszeichen im Passwort bringen die Syntax des Strings völlig durcheinander. An dieser Stelle war dann auch mein 64Bit Opensimulator mit der MariaDB lauffähig, und ich konnte mich um den Upload der OARs kümmern. Dafür gibt es mehre interessante Links:

http://opensimulator.org/wiki/Load_Oar_0.9.0+
http://opensimulator.org/wiki/Varregion
http://opensimulator.org/wiki/OpenSim_Archives

Als Erstes bin ich wieder genau der Anleitung gefolgt.

load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels

Dabei kommt es aber zu einem unschönen Fehler.
[LAND MANAGEMENT MODULE]: Cannot add parcel "Western Town", local ID 2 at tile 0,0 because this is still occupied by parcel "Your Parcel", local ID 1 in Midgard

Auch hierfür fand sich die Lösung im Metro-Forum in einem Beitrag von Pius Noel unter dem folgenden Link.
https://forum.metrogrid.de/discussion/50...egionen/p2

Es kommt leider dazu, daß für eine Parzelle aufeinmal zwei Namen in der Datenbank stehen und einer muss gelöscht werden. Dafür logge ich mich auf der Datenbankkonsole ein:

mysql -u root --password

Danach führt man die folgenden SQL Befehle aus, und löscht so den Namen "Your Parcel". Dabei muss die UUID des Namens "Your Parcel" verwendet werden:
SELECT UUID,Name FROM opensim.land;
DELETE FROM opensim.land where UUID = '11111111-2222-3333-4444-555555555555';

Schwierig könnte das mit der integrierten SQLite Datenbank werden, ich weiss momentan nicht ob man da überhaupt eine Konsole aufrufen kann. Aber man kann das Problem von vornherein vermeiden. Wenn man den OAR Load-Befehl für die erste Region verändert:

load oar oar00.oar --displacement "<0,0,0>" --merge --force-terrain --force-parcels
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels

Das Nette bei dieser Art des OAR Uploads ist es, das die ursprünglichen Sim-Namen als Parzellennamen erhalten bleiben. Ich habe dabei erst alle Regionen auf diese Weise hochgeladen, und erst danach mit allen neuen Regionen zusammen den Befehl "backup" und anschliessend ein "shutdown" ausgeführt. Das dauert dann natürlich trotz 64Bit System eine geraume Zeit. Das Ergebnis der ganzen Bemühungen ist ein System der folgenden Spezifikation:

CPU 10 Cores
RAM 64GB
upload: 12MBit/s
Var4x4 Region
ca. 92000 Prims
ca. 5500 Skripte

Normalerweise hatte ich vor mit einem geskripteten Auto auf der Sim herumzufahren, und zu schauen ob das flüssig geht. Bei den ersten Tests hab ich das aber aufgegeben. Nicht weil der PC an seine Grenzen war, die Upload Bandbreite von 12Mbit/s war der Flaschenhals. Die Datenrate ging immer wieder bis ans Limit und dann begann es natürlich leicht zu ruckeln. Der PC selbst war recht unbeeindruckt. Bei den folgenden Zahlen darf man aber nicht vergessen, daß auf dem PC noch der Viewer und andere auf einem Desktop übliche Programme wie ein Virenscanner liefen.

- 9GB belegter RAM
- im Mittel 15-20% CPU Last
- CPU Spitzenlast ca. 30%

Es ist jetzt natürlich schwierig hochzurechnen welcher Server bei einer var8x8 oder var16x16 notwendig ist. Geht man nur jeweils von einer Verdoppelung aus? Oder muss man doch berücksichtigen das eine Verdoppelung der Seitenlängen eine Vervierfachung der Fläche bedeutet? Ich denke das ein System entsprechend der Empfehlung Manfreds oben ein guter Startpunkt ist. Wenn ich allerdings seinen Beitrag genau lese, und meine Ergebnisse berücksichtige, ist seine Server Konfiguration eine Minimalforderung für eine Var16x16, sollte meiner Meinung nach aber für ein Var8x8 gut funktionieren.

https://www.gridtalk.de/showthread.php?t...5#pid41585

Aufgrund meines Ergebnisses ziehe ich die folgenden Konfigurationen in Betracht:
A) var8x8: V-Server 8Cores 32GB
B) var16x16: V-Server 16Cores 60GB
Da man V-Server leicht upgraden können sollte, könnte man natürlich auch mit dem kleineren System beginnen, und wenn es notwendig ist, den V-Server später upgraden. Soweit zu den technischen Gesichtspunkten. Mal sehen was das liebe Geld noch dazu sagen wird. :-)

[Pius Noel]

Wow, eine sehr schöne und gut detaillierte Beschreibung, wie ich sie schon lange nicht mehr gesehen habe, Jules.

Ich bin gespannt ob du es schaffst zu dem OAR von 2worlds2go zu kommen. Ich hatte mich dort mal registriert, aber nie eine Antwort mit einem Link bekommen mit dem ich die Registrierung abschliessen konnte. Auch im Spam ist nie etwas angekommen.

Da ich keinen entsprechenden Server mehr habe, habe ich mich aus der bisherigen Diskussion rausgehalten. Vor dem Hintergrund, dass es wohl kaum fertige OAR's gibt, die zu deinem Vorhaben passen, gehe ich davon aus, dass du wahrscheinlich über längere Zeit am Bauen bist. Von daher würde ich eher klein anfangen.

Wie du selber schon angemerkt hast kann man vServer oft problemlos und einfach upgraden. Aber selbst dann, wenn das nicht geht, ist ein Umzug von Opensim völlig problemlos. Mono, MariaDB und Opensim sind schnell installiert.

Sind die Vorbereitungen getroffen, einfach die Dateien der Konfiguration, ggf. benötigte Skripte und crontab-Einträge sichern und zusammen mit einem mysqldump der Datenbank auf den neuen Server übertragen wo man die Daten wieder einlesen kann. Hat man die beiden Server nicht gleichzeitig zur Verfügung, dann kann man die benötigten Daten vorübergehend auf dem Heimrechner oder einer Storage Box zwischenspeichern.

Auf Grund meiner eigenen Erfahrungen kann ich nur raten, darauf zu achten, dass man keine langfristigen Verträge eingeht. Also besser eine einmalige Gebühr von 5 Euro für den Setup bezahlen, wenn man damit eine minimale Laufzeit von 1 Monat hat, als diese 5 Euro einzusparen, aber ggf. auf einem Server der einem nicht gefällt, ein Jahr lang sitzen zu bleiben.

Ich machte z.B. einmal den Fehler, dass ich mich auf ein Schnäppchen mit einem Jahresvertrag eingelassen habe mit dem ich nicht zufrieden war und für das ich dann keine richtige Verwendung hatte. Da ich später auch noch die 3-monatige Kündigungsfrist vor Ablauf der Jahresfrist verpasst habe, musst ich den Server gleich nochmals für ein Jahr bezahlen. Ich hatte in der Euphorie das Kleingedruckte nicht gelesen und dafür teures Lehrgeld bezahlt.

Man sollte aber auch nicht gleich die Flinte ins Korn werfen, falls es mal beim Provider der Wahl nicht gleich von Anfang an klappen sollte, wie man es gerne hätte, sondern vielmehr zusammen mit bereits erfahrenen Betreibern gehosteter Regionen nach der Ursache der Probleme suchen. Die meisten Probleme lassen sich auf die eine oder andere Art lösen.

Ich wünsche dir einen guten Start und viel Spass mit deinen Projekten.

Pius /

[Christoph Balhaus]

Die Anmeldung bei 2worlds2go scheint im Moment gerade mal zu funktionieren. Ich habe einen Aktivierungslink bekommen (im Spamfolder) und konnte mich damit anmelden. Die mit dem Link aufgerufene Seite liefert eine Fehlermeldung, aber funktioniert hat es dennoch.

/Chris

[Jules Dreki]

@Pius Noel:
Vielen Dank für Deine netten Worte zu meiner Anleitung. Christoph hat mit der Anmeldung bei 2worlds2go recht. Das Airport OAR hätte ich schon bekommen können. Allerdings erschienen mir die Einschränkungen durch die Lizenz zu stark, daher habe ich es besser gelassen. Wenn ich lange am bauen bin um so besser Pius. ;-)

Zu den Server Ressourcen habe ich mich noch nicht endgültig entschieden, aber die Variante var16x16: V-Server 16Cores 60GB ist wahrscheinlich doch etwas übertrieben. Ich tendiere dazu zwar eine var16x16 aufzusetzen, aber mit einem V-Server 8Cores 32GB zu beginnen.

[Mareta Dagostino]

16x16 ist wirklich riesengroß, das entspricht doch 256 "normalen" Regionen auf einem Rechner! Du testest damit Grenzen aus. Wenn du eh selber die Region bebaust, dann würde ich erst mal eine 8x8 nehmen und schauen wie sich die fliegt. Man kann ja jederzeit vergrößern, solange keine Nachbarn im Weg sind. (Nachbarn solltest du bei solchen Riesenregionen eh vermeiden, weil Nachbarn die Performance einer Region deutlich reduzieren.) Es gibt noch einen unangenehmen Effekt bei Riesenregionen: Das Bodenmesh wird entsprechend groß, und alle Besucher benötigen entsprechend leistungsfähigere Computer.

Liebe Grüße, Mareta

[Manfred Aabye]

Durch die neuen Funktionen des OpenSimulators kannst du auch in Großen Regionen kleine einfügen.

Du möchtest eine 256er Flugplatz-OAR zweimal in eine große 4096 Region kopieren, einmal Links unten und gedreht Rechts oben.
change region GrosseFlugRegion
load oar --merge --force-terrain --force-parcels --displacement <0,256,0> Flugplatz-OAR.oar
load oar --merge --force-terrain --force-parcels --rotation 180 --displacement <3840,3840,0> Flugplatz-OAR.oar

;Beispiel für eine Regions.ini
[GrosseFlugRegion]
RegionUUID = 118a3c3e-f37a-443a-a2f0-a3285baae9ad
Location = 1000,1000
InternalAddress = 0.0.0.0
InternalPort = 9050
AllowAlternatePorts = False
ExternalHostName = 127.0.0.1
SizeX = 4096
SizeY = 4096
SizeZ = 4096
DefaultLanding = <128,128,30>
NonPhysicalPrimMax = 1024
PhysicalPrimMax = 64
ClampPrimSize = False
MaxPrims = 45000
MaxAgents = 40

[Pius Noel]

Aus reiner Neugier habe ich gestern noch einen Versuch gestartet und zuerst eine leicht bebaute 8x8 VarRegion erstellt, die ich später auf eine 16x16 VarRegion erweitert habe.

Der Unterschied war deutlich grösser als ich erwartet hatte, denn es ist vermutlich genau das eingetreten, worauf Mareta hinsichtlich des Bodenmesh hingewiesen hat. Während bei der 8x8 VarRegion noch alles einigermassen gut lief, hat sich die Erweiterung auch auf den Aufbau der Bodentexturen ausgewirkt, die nur noch schubweise erschienen und ich hatte auch immer wieder starkes Ruckeln.

An der Serverleistung kann es kaum gelegen haben, denn die war konstant nicht ausgelastet und höchstens mal kurz für einzelne Kerne im oberen Bereich. Ansonsten habe ich kaum eine Auslastung von über 25% beobachtet.

Später habe ich noch einen draufgesetzt und eine Mall von Linda Kelley sowie eine kleine Stadt mit Flugplatz und Hafen hinzugebaut. Am Ende des heutigen Tages hatte ich einen Landimpakt von rund 76'000 bei einer bebauten Landfläche die ca. 16 Einzelregionen entspricht und gerade mal 6.5% des gesamten verfügbaren Landes entspricht. Der Rest ist Wasser, Wüste und Hügel.

Während des Bauens hatte ich immer wieder mal überraschende Effekte. Mal war der Steg weg, dann das Boot. Neben der Mall ist plötzlich ein Leuchtturm aufgetaucht, der vorher nicht da war. Und immer wieder war kein Wasser da oder ich hatte braune Hügel, die eigentlich grün sein sollten.

Auf der Region laufen 3600 Skripte (das meiste vermutlich Vendoren und Türscripte aus den geladenen OARS, rund 800 sind von meinen eigenen Objekten). Der Start der Scripte dauert dabei rund 9 Minuten bevor das Login freigegeben wird.

Fliegen mit meinem Hubschrauber konnte ich nicht, da ich zuerst die Scripte anpassen muss, da ich sie so gebaut hatte, dass ich auf meiner früheren Region nicht zu nah an den Rand kommen konnte, wo ich dann stecken blieb.

Mit meinem Boot lief es überraschend gut und schnell. Ab und zu ein Ruckeln, aber soweit ok. Das blöde ist nur, dass das Rezzen der Texturen nicht mitzuhalten vermag und sich das graue Knäuel an Land erst beim zurückschauen als Baum entpuppt. Problematisch war es ganz allgemein, auf meinem Rechner die best mögliche Drawing Distance zu finden.

Fahren in der Stadt mit einem Fahrzeug läuft gut, wenn einmal alle Texturen geladen sind und die Drawing Distance unter 256 gehalten wird, was dafür reicht. Das war die einzige Situation wo ich sagen kann, dass sich die Grösse der Region kaum bemerkbar macht.

Erwähnen muss ich vielleicht noch, dass ich alles was irgendwie geht jeweils auf Phantom setze um jegliche Kollisionen zugunsten der Performance zu vermeiden. Dass man dabei ungehindert durch Bäume und Büsche gehen kann stört mich nicht weiter (OT: nur so habe ich es auch geschafft eine ganz interessante Region relativ problemlos auf einem Raspberry Pi 3 während 2 Monaten am Leben zu erhalten).

Da ich früher im SL auch gerne mit Hubschraubern über weite Strecken geflogen bin und die Meere mit dem Segelboot erkundet hatte, kann ich den Wunsch nach grossen Regionen gut nachvollziehen. Aber in der Welt von Opensim hatten sich meine Träume schnell relativiert und die grösste Region, die ich jemals hatte, war eine 3x3 VarRegion. Deshalb war mir auch nicht klar, welche Auswirkungen eine grosse VarRegion mit sich bringt. Der Server ist übrigens ein vServer mit 32 GB RAM, 8 Kernen und schneller SSD. Die Leistung würde noch weit reichen.

[Christoph Balhaus]

Ein interessanter Thread. Wir (meine Freundin und ich) beschäftigen uns zur Zeit auch mit dem Aufbau eines Segelgrids, mit dem Ziel mittelfristig eine SL vergleichbare Qualität der Simulation zu erreichen und hoffentlich irgendwann auch besser zu werden. Mich interessiert die Spieleentwicklung ganz allgemein, aber in OpenSim zur Zeit am meisten der Performanceaspekt, wobei das bei der Optimierung der Modelle beginnt und die Scripte bis hin zum Netzwerkcode umfasst.

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. Das hat mehrere Gründe:

Zum einen ist die Fläche mit einer einzelnen Region immer begrenzt, egal wie gross man sie wählt und eine mögliche Skalierung in der Größe war uns wichtig. Es erlaubt uns, ausgehend von einer Kernregion und aufbauend auf archivierte OARs schnell weitere Flächen hinzuzufügen (unter Verwendung zusätzlicher Hardware) und auch die Anordnung der Inseln in dem Segelrevier flexibel zu ändern. Wir bauen eine Insel in so einer Kachel und schieben sie später dorthin wo es am besten zur gewählten Geometrie passt. Diese 2x2 Var Regionen verwenden wir durchgängig im gesamten Grid, so dass wir auch Sims aus anderen Projekten problemlos hinzufügen können.

Auch die Verteilung der Last auf die einzelnen Kerne ist so wahrscheinlich günstiger. Wir haben die Anzahl der Simulatoren an die Anzahl der Kerne angepasst, aber auch da gibt es noch viel Spielraum zum Experimentieren und für Verbesserungen.

Die Größe der Var Regionen ergab sich aus einem Kompromiss aus erforderlicher Sichtweite und Performance. Da Opensim nur erlaubt in benachbarte Regionen zu schauen, ist die Sichtweite bei Standardsims auf, im ungünstigsten Fall, 256m beschränkt. Das erscheint mir zum Segeln zu wenig. Grössere Regionen als 2x2 haben hingegen den Nachteil, dass beim Simcrossing zu viele Daten (insbesondere Terrain) geladen werden müssen, was zu unschönen Verzögerungen führt. Mit 2x2 Var Regionen können wir immerhin mindestens 512m Sichtweite garantieren, was aus der Erfahrung in SL schon ganz akzeptabel ist.

Größtes Problem bleiben, hinsichtlich der Geometrie, die Simcrossings. Durch ein einfaches 'Preloading' der Caches haben wir es erreicht, dass die Latenzen beim Simübergang von der Komplexität der Modelle nicht mehr so stark beeinflusst werden und zum Segeln ist die Performance bei wenigen Booten auch jetzt schon recht gut, allerdings macht schnelles fliegen noch nicht so viel Spass. Allenfalls mit Modellen wie unseren Hoverbikes, mit denen auch langsameres fliegen sinnvoll ist,stören sie nicht so sehr. Aber das wird sich auch noch verbessern. Für alle Sims eines Servers verwenden wir gemeinsame shared Binaries und damit auch einen gemeinsamen Cache. Das erleichtert auch die Konfiguration und soll in Zukunft auch den Aufwand für Upgrades und Erweiterungen reduzieren.

Insgesamt steht bei dem Projekt aber mehr der Aspekt des Lernens und des Experimentierens im Vordergrund als die Absicht in kurzer Zeit was Vorzeigbares zu schaffen. In dem Sinne wird uns das Projekt auch noch eine ganze Weile beschäftigen :-)

/Chris

[Pius Noel]

Kleine Var- und Einzel-Regionen und waren auch immer meine Devise. Auf Metropolis hatte ich diese seinerzeit nur wegen den Anschlusskosten* und weil das Border-Crossing wegfällt zu grösseren Regionen zusammengefasst.

Darüber hinaus hatte ich auch Gruppen von Regionen zusammengefasst, die unter eigenen Simulator-Instanzen liefen. So war es möglich einen Teil der Regionen neu zu starten während immer noch ein Teil weitergelaufen ist. Auch das hochfahren der Regionen konnte so gesteuert werden, so dass wichtige Regionen schnell wieder bereit waren, während z.B. eine Mall mit vielen Scripten erst nach drei Minuten gestartet wurde.

Da ich bis vor einem Jahr noch mit OpenSim 0.8.3 unterwegs war, hatte ich es bisher verpasst mich vertieft mit den Übergängen bei den neueren Opensim-Versionen zu befassen. Das sollte ich mal nachholen, vielleicht lassen sich dann meine Träume von 2014 doch noch verwirklichen

Es gibt eine Sache, die ich bei meinen Tests am Wochenende nicht ganz verstanden habe. Ich hatte von allem genügend: genügend CPU-Leistung und RAM am vServer (Xeon Gold mit 8 vCores und 32 GB RAM, Stealth habe ich nie gesehen), meine CPU Leistung am PC (i7/4770) war zwischen 10% und 25% ausgelastet (ich habe nie mehr als 45% gesehen), Bandbreite Server zu PC liegt bei 53 MBit/s (PC zu Server weniger konstant aber immer noch > 50 MBit/s), Netzwerk-Lag konnte ich keinen feststellen, meine Grafikkarte (Geforce GTX 660) ist um die 10% ausgelastet... wo ist denn der Engpass?

Wie auch immer, ich bleibe noch ein bisschen am Thema werde aber wieder auf meinen viel kleineren vServer, den ich noch habe, zurückgehen

P.S. *) ist eigentlich nicht meine Art

[Christoph Balhaus]

Ich lehne mich jetzt mal ganz weit aus dem Fenster, vielleicht zu weit, weil ich mich mit dem Threadmodell von C# und den Threadpools wie Opensim sie verwendet nicht auskenne, aber ich würde in folgender Richtung suchen:

Opensim macht sehr ausgiebig Gebrauch von Threads und bezieht die aus Threadpools. Ich vermute sehr stark, dass es sich dabei aus Effizienzgründen um User Threads bzw. Light-Weight Threads handelt, also Threads die im Userspace verwaltet werden. Die wiederum basieren auf einer beschränkten Zahl von Kernel Threads, vielleicht auch nur einem, was zur Folge hätte, dass sie sich alle auf einem einzigen Kern drängen und es dort trotz der vielen Kerne zu Engpässen kommen kann. Deswegen versuche ich die Last immer möglichst gleichmässig auf mehrere Opensim Instanzen zu verteilen, was bei einer sehr grossen Region natürlich nicht geht.

Ich habe genau das auch häufiger als eine auf Beobachtungen basierende Empfehlung gehört, was die Vermutung stützen würde.

Aber wenn sich jemand an der Stelle des Codes besser auskennt, würde ich mich auch gerne belehren lassen :-)

/Chris

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.