Homepage
SVN-Tracker
SVN-Archive deutsches-HOWTO
Homepage
SVN-Tracker
SVN-Archive deutsches-HOWTO
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.
| 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.
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.
Hierbei
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.
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] |
| 92.51.141.98 | 32 | 98 | 10.751,38 | 10.779,49 | 21.530,87 |
Wir reden also von 21.500 MB - die meisten Angebote beinhalten bei weitem das Vielfache an Traffic.
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...