Sizing

 

Die nachfolgende Tabelle ist keine exakte Wissenschaft, da sich Parameter ständig verändern.

Allerdings ist sie das Ergebniss aus eigener Betriebserfahrung auf diversen Servern, verschiedenen Betriebssystemen und mit über 60 produktiven Regionen in Osgrid.

Ebenso sind alle Benchmarks von (UCI, Intel, eigene, osgrid Foren) und Erfahrungswerte eingeflossen, die andere berichtet haben.

Viele Faktoren sind extrem abhängig von deiner Nutzungsart - manche nutzen komplexe Scripte (groß, Listener, Arrays, z.b. Radar), andere simple "touch-Türöffner". Manche haben viel Traffic (viel Caching, viel ad-hoc Speicherbedard - andere eher selten.

 

Das Ziel der Ausführungen ist auf jeden Fall Stabilität mit akzeptabler Performance.

 

RAM

Was Speicherbedarf Anzahl bei dir deine Summe
Simulator pro Instanz 35 MB    
Region pro Instanz 15 MB    
20 Prims 1 MB    
6 Scripte 1 MB    
       
       
    Summe:  

 

Folgende Zusatzfaktoren kommen dazu:

Einfluss durch Bedarf deine Summe
Caching der Region ca. 20 - 35% der leeren Region nach 24h  
andere Datenbanken als sqlite (benutzt du MySQl, schau wie viel dein Datenbankserver verbraucht)    
Avatar 10 MB  
save oar bis zu 105% des RAM-Bedarf der Region  

 

Nachdem alles summiert ist, kommt ein Aufschlag von 25% hinzu um wechselnde Lastsituation (mehrere per Teleport einkommende Avatare etc.) abzudecken.

 Das geht alles mit weniger RAM ?  Bravo !   Siehe die Ausführungen oben. Klar geht es - je nach Nutzungsverhalten - und je nach Anforderung an Stabilität und Performance.

 

Netzwerk

 

Avatare benötigen alle "gegenseitig" Updates ihres Aussehen, Position etc. Hierbei gilt:

Zahl der Übetragungswege =  Avatare 2

 

Dies ist meist auch das Limit für Homeserver bei 5-6 Avataren, wo Lag einsetzt. (Hier zählt der Upstream).

 

Zusätzlich die die Zahl der benachbarten Regionen und die Drawdistance der Avatare in einem 512m Umkreis relevant.

 

Da die Regionen selber z.b. auch die Weltkarten-Images an alle Viewer versenden, führen schmallbandig angebundene Server zu Wartezeiten für alle - dies liegt i.d.R. nicht an opensim oder dem Grid.

 

Latency

 

Ganz entscheidend für stabile und schnelle Teleports und Regionswechsel, ist eine geringe Latency. Dies wird künftig mit z.B. Fahrzeugen noch relevanter werden.

 

aufzeichnen3Hierbei ist zu beachten, dass die Verbindungen zwischen Herkunftsregion, Zielregion, Gridserver (Location Register, wo befindet sich Avatar/Prim) und Viewer betrachtet werden müssen.

 

Dies ist ein Kernkriterium bei den Providerempfehlungen und oft ein Problem bei Homeservern.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Bandbreite (Traffic)

Beispiel basierend auf dem Server a) aus dem Sizingbeispiel weiter unten.

 

Akt. Datum: 03.01.2009 Zeitraum: 01.12.2008 - 31.12.2008
Netz Maske bis IP IN [MB] OUT [MB] Summe [MB]

21.530,87

 

Wir reden also von 21.500 MB - die meisten Angebote beinhalten bei weitem das Vielfache an Traffic.

 

 

CPU

Die CPU-Last ist im wesentlichen abhängig von:

- Avataren

- Skripten

- TreePopulator

 

 

Die Seite wird über die Zeit ausgebaut / aktualisiert.

 

 

23.3.09

 

Beispiele auf Basis Opensim 6.1 und 6.2:

 

 

 

Sizing (grob):

Landschaft mit max. 250 Prim -> 256MB

Openspace mit max. 1500 Prim --> 512MB

reguläre Region --> 1GB

high Prim mit viel Verkehr --> 2GB (noch nicht praktisch gesehen)

Windows braucht etwas mehr, Linux etwas weniger.  Vieles ist von praktischer Erprobung abhängig, schliesslich spielen nicht nur Server-CPU, Ram und Prims - scripte - avatare - Physik eine Rolle. Auch der persönliche Eindruck was "geht" und was nicht ist subjektiv.

 

Beispiele:

 

a) Server 2003 - 1GB - VPS
7 regions in 2 SIMs (opensim instances) based on a shared sqlite
serving ~ 6000 prims , 300 scripts - have had up to 12 avatars on region

b) Linux 10.3 - 768MB - VPS , running a web and mailserver
1 region - Sandbox

c) SuSe 11.1 - 1GB - native
22 regions, just some palms - water...