• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Stabilität von OpenSim

Eckbert Domzarjs

Neuer Nutzer
Hallo,

ich teste derzeit OpenSim auf einem vServer.
Weil es nur ums Testen geht, habe ich ihn nur als Standalone mit SQL-Lite konfiguriert, das fertige Debian-Paket von der Version 0.6.6. genommen und auf einem Beta-vServer von **** mit 1 Gb RAM installiert (ich weiss, dass das etwas unterdimensioniert ist, aber mir gings auch nicht um den Produktiveinsatz, sondern ums Antesten).

Viele Sachen funktionieren, aber:
- Wenn ich 3D-Objekte hochlade (anstatt sie InWorld zu builden) beendet sich der Server. Sehr selten crasht er auch ohne konkreten Anlass. Ich nehme an, das liegt dann an dem wenigen RAM?
- Wenn nach einem Crash der Server neu gestartet wird, dann sind alle in der letzten Sitzung vorgenommenen Änderungen (z.B. InWorld gebaute Objekte) nicht mehr anzutreffen. Ist es so, dass bei SQLite diese Änderungen erst bei ordentlicher Beendigung des Server-Daemons dauerhaft gespeichert werden, und bei einem Crash deswegen gar nicht? Wenn ich stattdessen MySQL verwende, werden dann Änderungen immer sofort in die Datenbank geschrieben?

Wenn ich irgendwannmal soweit sein sollte, ein OpenSim-Grid im Produktiveinsatz zu nutzen, was für ein Server sollte man dann Minimum bereitstellen für ca. 5 Nutzer die gleichzeitig online sind und Umgebungen, die nicht zu viele Prims enthalten? 2 Ghz CPU und 2 Gb RAM?
Also welche Leistung bräuchte man, damit er nicht dauernd abstürzt.

Und was ist die sinnvollste Methode, um den Server-Daemon direkt neu starten zu lassen, falls er sich mit einem unerwarteten Fehler beendet?
Ein Shell-Script, dass in einer Endlos-Schleife "mono Opensim.exe" aufruft, und das ganze dann per "screen" in den Hintergrund gepackt?
 
Hallo Eckbert,

ich nutze zwar selbst OpenSIM nicht, aber eine Aussage zum Auto.Neustart:

Das würde ich unter Linux mit einem CRON-Job machen.

Nutze ein Script, das feststellt, ob der SIM-Server noch läuft. Hierzu lassen sich z.B. Prozessparameter oder ein Ping auf einen SIM-Daemon verwenden, sofern openSIM das unterstützt.
Wenn dieses Script feststellt,dass ein Prozess nicht mehr läuft, kann es einen Neustart auslösen.

Pack das Script als Startbefehl z.B. alle zwei Minuten in die crontab-Datei. Das hat den Vorteil, dass es wirklich nur alle zwei Minuten kurz aktiv ist, anstatt ständig irgendwo im Speicher rumzuschwirren.

ABER: Auto-Restart hat auch einen Nachteil: Wenn ein Crash z.B. Daten zerschossen hat, kann der folgende Restart unter Umständen noch mehr Schaden anrichten.

SIM_Ressourcen (RAM etc).. such mal auf den Seiten von Ralf Haifisch, ralf hat eine ganze Menge Scripte und Hintergrund zusammen getragen. wenn ich mich recht entsinne, auch den Ressourcenbedarf für OpenSIM. So viel RAM braucht der glaube ich gar nicht zwingend - schaden tut RAM, insbesondere bei einem Server, nie.

Datenspeicherung: ich vermute(!) mal, das SQlite und MySQL die Daten im RAM halten und regelmäßig oder bei Bedarf ein Flush auf die Platte ausgelöst wird, das ist üblich. MySQL kann beträchtlich Speicher in Anspruch nehmen, das lässt sich konfigurieren- bis zu 50 ...80% des RAM werden bei größeren Datenbankservern dafür hergenommen. Wenn so eine DB crasht, sind neuere Items weg - sprich, alles, was vor dem letzten Wegschreiben auf die Platte erstellt worden ist.

Warum die Maschine crasht, kann ich mangels Erfahrung mit OpenSIM nicht sagen... 1 GB sollte an sich nicht der Grund sein. Was sagen denn die Logeinträge?
 
Zunächst mal danke für deine Antwort, Yistin.

ich nutze zwar selbst OpenSIM nicht, aber eine Aussage zum Auto.Neustart:
Das würde ich unter Linux mit einem CRON-Job machen.
(...)
Pack das Script als Startbefehl z.B. alle zwei Minuten in die crontab-Datei. Das hat den Vorteil, dass es wirklich nur alle zwei Minuten kurz aktiv ist, anstatt ständig irgendwo im Speicher rumzuschwirren.

Klingt plausibel. Aber verursacht ein 3-Zeiliges Shell-Skript, dass die meiste Zeit herum idlet, wirklich mehr Systemlast als ein Cron, der alle zwei Minuten aufgerufen wird?

ABER: Auto-Restart hat auch einen Nachteil: Wenn ein Crash z.B. Daten zerschossen hat, kann der folgende Restart unter Umständen noch mehr Schaden anrichten.

Hmm, das stimmt...
Vielleicht könnte ich jeden Morgen einen anderen Cron laufen lassen, der ein DB-Backup macht und das Backup remote woanders hin kopiert.
Aber die Benutzer wären dann verwirrt, wenn sie nach dem automatischen Neustart sich einloggen könnten, das Server-Backup aber noch nicht wiedereingespielt wäre (und aufeinmal ihr Inventar leer ist o.ä.).

Warum die Maschine crasht, kann ich mangels Erfahrung mit OpenSIM nicht sagen... 1 GB sollte an sich nicht der Grund sein. Was sagen denn die Logeinträge?

Ich hab mal aus der /var/log/opensim/OpenSim.log drei Einträge rausgesucht, von denen ich glaube, dass um diese Uhrzeiten der Server crashte (sind auch alle drei als "Exception"-Ereignisse benannt):

Code:
ERROR - OpenSim.Region.Physics.OdePlugin.OdeScene.MeineWelt [PHYSICS]: Cannot  cast from source type to destination type., Void near(IntPtr, IntPtr, IntPtr), System.InvalidCastException: Cannot cast
from source type to destination type.
at OpenSim.Region.Physics.OdePlugin.OdeScene.near (intptr,intptr,intptr) <0x0174c>
at (wrapper native-to-managed) OpenSim.Region.Physics.OdePlugin.OdeScene.near (intptr,intptr,intptr) <0x00049>
at (wrapper managed-to-native) Ode.NET.d.SpaceCollide2 (intptr,intptr,intptr,Ode.NET.d/NearCallback) <0x00004>
at OpenSim.Region.Physics.OdePlugin.OdeScene.collision_optimized (single) <0x0034d>
at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate (single) <0x0148c>
Da hatte die per PlugIn eingebundene Physik-Engine ein Problem und der Open-Sim Daemon wurde beendet (davor und danach machte die Physik nie wieder Probleme).

Code:
DEBUG - OpenSim.Region.ScriptEngine.XEngine.XEngine [XEngine] Loaded script Maschine.Rotieren
ERROR - OpenSim.Application [APPLICATION]: M
APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgsM
M
Exception: System.NullReferenceException: Object reference not set to an instance of an object
  at System.Timers.Timer.StartTimer () [0x00000]
  at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()M
M
Application is terminating: TrueM
Hier crashte der Server, als für das Objekt "Maschine" das LSL-Skript "Rotieren" ausgeführt wurde. Bei einfacheren Objekten gabs mit dem selben Skript keinen Crash (--> mangelnde Ressourcen?)


Code:
ERROR - OpenSim.Region.ClientStack.LindenUDP.LLClientView System.NullReferenceException: Object
 reference not set to an instance of an object
  at OpenSim.Region.ScriptEngine.XEngine.EventManager.touch_start (UInt32 localID, UInt32 originalID, ...
Keine Ahnung, was mir das sagen soll...
 
Hallo,

ich teste derzeit OpenSim auf einem vServer.
Weil es nur ums Testen geht, habe ich ihn nur als Standalone mit SQL-Lite konfiguriert, das fertige Debian-Paket von der Version 0.6.6. genommen und auf einem Beta-vServer von **** mit 1 Gb RAM installiert (ich weiss, dass das etwas unterdimensioniert ist, aber mir gings auch nicht um den Produktiveinsatz, sondern ums Antesten).

Debian? Au weia. Erstmal, bevor man rumrät: welche Versionsnummer trägt denn dein Mono? Welche Debilian-Version setzt du auf dem Server ein?

Debian würde mir da ein wenig Bauchschmerzen bereiten, denn die sind immer von der Versionierung her sehr konservativ (sprich: für solche Zwecke veraltet), währenddessen Opensim Bleeding Edge ist und gerade an Mono+Libs sehr aktuelle Versionen voraussetzt. Nutzt du Backports? Für Opensim wäre Debian jedenfalls nicht unbedingt meine erste Wahl.

Außerdem: womit lädst du die 3d-Objekte hoch? Emerald, Meerkat, irgendwas...?
 
Zunächst mal danke für deine Antwort, Yistin.



Klingt plausibel. Aber verursacht ein 3-Zeiliges Shell-Skript, dass die meiste Zeit herum idlet, wirklich mehr Systemlast als ein Cron, der alle zwei Minuten aufgerufen wird?
Systemlast kaum. ich mag's nur gerne genau definiert und sauber... ein Dreizeiler? Würde ich eh nicht machen. Wenn ein Test "Daemon läuft" ergibt --> Beenden.
Wenn ein Test "Daemon läuft nicht" ergibt, würde ich zunächst einige Sekunden warten und nochmals testen. Erst wenn 3 - 4 Tests hintereinander ein "Läuft nicht " ergeben haben, würde ich neu starten. Ansonsten könnte eine lastintensive Prozedur auf dem Server einen Neustart auslösen, schlicht weil die Antwort zu spät kommt...

Hmm, das stimmt...
Vielleicht könnte ich jeden Morgen einen anderen Cron laufen lassen, der ein DB-Backup macht und das Backup remote woanders hin kopiert.
Aber die Benutzer wären dann verwirrt, wenn sie nach dem automatischen Neustart sich einloggen könnten, das Server-Backup aber noch nicht wiedereingespielt wäre (und aufeinmal ihr Inventar leer ist o.ä.).
Dafür gibt es - zumindest unter MySQL - ein geniales Script: AutoMySQLBackup (Suchen bei Sourceforge.net]. Das Script legt automatisch Backups der MySQL-Datenbanken an - Monatlich, wöchentlich und einmal pro Wochentag. Die Backups "per Day" werden nach einer Woche überschrieben. Die anderen werden mit Datum abgelegt und müssen gelegentlich mal von Hand gelöscht werden, wenn es zuviel wird.
Das Ergebnis der Sicherung sind fertige SQL-Scripte. zum wieder Einspielen reicht also ein "mysql < backupdatei" und Username/Kennwort für den SQL-Server.

Diese könnte man ggf. bei einem Neustart sogar automatisch einspielen - davon würde ich aber die Finger lassen. damit macht man u.U. mehr Kaputt als Heile. Besser herausfinden, warum die Kiste kracht.

Ich hab mal aus der /var/log/opensim/OpenSim.log drei Einträge rausgesucht, von denen ich glaube, dass um diese Uhrzeiten der Server crashte (sind auch alle drei als "Exception"-Ereignisse benannt):

Da muss ich passen, das sind den Meldungen nach Innereien aus dem openSIM - keine Erfahrung, Sorry..

Die Einwände von Bart sind m. E. berechtigt, hab ich gar ned dran gedacht... Debian ist ein recht guter (und stabiler) server, wenn es um Dateiserver, mail Web oder so geht... Für openSIM ist er eher fragwürdig, Bart hat ja beschrieben, warum.
 
@Yistin:
Ok, danke. Werde das dann so mit dem Skript und den Datenbank-Backups umsetzen.

@Bartholomew:
Auf dem Server nutze ich Debian 5.0 (Lenny).
Mono gibt als Version 1.2.6. aus.
Backports nutze ich keine (war für meine bisherigen Zwecke nicht notwendig, und mir ist es etwas unangenehm, Pakete aus verschiedenen Quellen miteinander zu mischen).
Die 3D-Objekte habe ich mit dem "'RealXtend Viewer" hochgeladen.

Welche Distri ist denn aktuell genug für OpenSim?
Habe im Server-Bereich bisher leider nur mit Debian zu tun gehabt, deswegen würde ich ungern eine mit einem komplett anderen Konzept verwenden (also Gentoo möchte ich mir z.B. ersparen, wenn man da alles selbst compilieren muss etc.).
Ist Ubuntu für den Server-Einsatz inzwischen ausgereift und für OpenSim aktuell genug?
Oder sollte man Fedora nehmen (hatte ich allerdings auch noch nicht mit zu tun) ?
 
@Bartholomew:
Auf dem Server nutze ich Debian 5.0 (Lenny).
Mono gibt als Version 1.2.6. aus.
Backports nutze ich keine (war für meine bisherigen Zwecke nicht notwendig, und mir ist es etwas unangenehm, Pakete aus verschiedenen Quellen miteinander zu mischen).
Die 3D-Objekte habe ich mit dem "'RealXtend Viewer" hochgeladen.

Welche Distri ist denn aktuell genug für OpenSim?

Schau dich mal in Ruhe auf Main Page - OpenSim um, da ist nun wirklich alles sehr gut dokumentiert. :!:

Also: Mono 1.2.6 ist hoffnungslos veraltet. Dein Opensim setzt mindestens Version 2.4.2 voraus laut Homepage. Das kann daher so nicht laufen. Es ist in deren Wiki für viele Distris dokumentiert, bei Debian empfehlen sie Eigenkompilat. Ansonsten schau dir mal Opensuse, Ubuntu Server oder Fedora an.
 
Ich selber betreibe meine "Dorenas World" ebenfalls auf einem V-Server mit Debian 5.0 Lenny

Um backports wirst du da wohl kaum rumkommen,nur auf diese Weise konnte ich auf eine aktuellere Mono-Version updaten.

einen cron-Job würde ich auch net nehmen,sondern es lieber über screen laufen lassen.

Dieses überprüft automatisch den status deiner opensim und startet sie nach einem crash automatisch neu.

Ausserdem kommst du damit auch wieder über ssh in die opensim-Konsole.

Feine Sache:)

Als webinterface für den Debianserver selbst nutze ich webmin.

Damit ist es auch recht einfach ohne phpmyadmin die mysql-Datenbank zu verwalten und ein automatisches Backup einzurichten.

Wie gesagt,alles erprobt und 24/7 online

Welcome to Dorenas World
 
Hallo,

ich hab mal eine Frage zur Hardware. Bis jetzt hab ich viel widersprüchliches gelesen. Der eine sagt einen VServer kannst du vergessen, der andere behauptet das Gegenteil. Der eine sagt nimm Linux da wird der Speicher besser verwaltet der andere sagt mit Windows und du sparst die Hälfte an Speicher. Auch beim Thema Traffic scheiden sich die Geister.
Mir wäre mal die Meinung von Leuten wichtig die eine Region betreiben, also keine Theorien und Annahmen, mehr so die "Erfahrung aus dem Leben".
Mir steht ein Dell PowerEdge 8 Core V-Server mit 3GB "garantiertem" RAM und gut 100MB Speicherplatz zur Verfügung. Auf dem Teil läuft Windows Server 2003. Im Monat darf ich 5000 GB Traffic erzeugen/verbrauchen. Im Prinzip möchte ich mich ans OSGrid hängen und das ganze zum bauen, probieren und rumspielen benutzen. Mehr als 5 User gleichtzeitig werden es wohl nicht werden. Kann ich mit dem oben genannten Teil etwas anfangen? Wenn ja , wieviel Regionen lassen sich damit betreiben oder soll ich das ganze lieber vergessen?

Gruß
 
Denke mal du meinst 100GB und net 100MB Speicherplatz,oder? Sonst wird es verdammt eng

mein v-server ist um einiges leistungstärker,abermehr als 5gig fest zugesicherten ram hab ich auch net,10gig dynamisch,was im ungefähren die swabdatei bei einem hardware Linuxserver darstellt

bei mir laufen alle Dienste,6 Regionen bisher,einige auch net zu knapp bebaut.

Mit allem komme ich auf unter 1gig Rambedarf, Wenn ich eine einstellung in der Xengine vornehmen würde,wäre es knapp die Hälfte, nur würden dem dan einige debug Funktionen zum Opfer fallen.

einen v-server würde ich aber niemals so rechnen wie einen Hardwareserver,da du beim V die Hardware mit etlichen Leuten teilen musst. Deswegen lieber unter der Belastung bleiben,diedie Serverdaten theorhetisch zulassen würden.

Mit 5 terra traffic,..vergiss es,...kommste wahrscheinlich nieeeeeeemals ran,kein Thema.

da du dich ans osgrid hängen willst fällt die Belastung durch die Serverdienste eh weg.

Denke so um die mindestens 20 Regionen könntest du damit fahren,theorhetisch sogar mehr.
Hängt ganz davon ab wie weit du die Regionen ausbaust.
Ich gehe lieber noch wiet unter den möglichen Rahmen,wegen eben..V-Server

Hab schon von Leuten gehört die mit 3gig wesentlich mehr regionen betieben haben
 
Hallo Dorena,
ja es sind 100GB - sorry. Also dürften 4 Regionen kein Problem sein? Wobei die mittelmäßig bebaut sind/werden - so 5000 bis 7000 Prims. Ich wollte erstmal nur mein "second life" retten, also mein Werke in das OSGrid übertragenn, weil ich schlicht und einfach von SL die Schnauze voll habe. OK, das ist ein anderes Thema.
Aber noch eine Frage zum Betriebssystem. Zur Zeit ist auf dem Server "Windows Server 2003" installiert. .Net Framework 3.5 SP1 und mySQL ist da auch drauf. So wie ich es verstanden habe kann ich es also auf Windows installieren. Bringt ein Linux System Vorteile? (Mal abgesehen von der Servermiete die aber eh schon bezahlt ist.) Wenn ja welche Distribution wäre zu empfehlen? Wobei ich dazu sagen muss das ich LSL beherrsche, schöne Sculpties und Texturen machen kann aber das fummeln an Linuxsystemen nicht so ganz mein Ding ist. Kurz und gut - es sollte einfach sein


LG
 
Linux bringt in dem Fall bis auf womöglich eine Fernwartung auf Shellebene keine nennenswerten Vorteil. Im Gegenteil, manche sag(t)en sogar, dass .NET zum Laufen lassen die bessere Umgebung sei als Mono, da es z.B. mehr Avatare gleichzeitig verkraften würde.

Für das, was du machen willst, sollte es mehr als ausreichend sein. Ich las einmal, bei Opensim gehen sie pro Avatar von ca. 20 MB Speicherbedarf aus, den man braucht, um den zu verwalten, es kann auch sein, dass das inzwischen weniger ist. Der Kontext war damals der Loginrekord auf Wright Plaza im Osgrid.
 
Na wenn du schon einen Win-Server hast umstellen auf Linux würde ich net.

Ich habe mich für die die Linuxvariante bei der Neuanschaffung aus Kostengründen entschieden,zumal ich das Linux-Debian schon länger kenne.

Bei einem reinen Web und fileserver wäre Linux für mich immer noch die erste Wahl, bei OS bin ich mir da net so sicher,würde generell keine Hand dafür ins Feuer legen
 
Linux bringt in dem Fall bis auf womöglich eine Fernwartung auf Shellebene keine nennenswerten Vorteil. Im Gegenteil, manche sag(t)en sogar, dass .NET zum Laufen lassen die bessere Umgebung sei als Mono, da es z.B. mehr Avatare gleichzeitig verkraften würde.

Ja, da hast recht .NET funktioniert vielleicht ein wenig besser. Ist ja klar Microsoft definiert den Standard und hat gleich die Referenzimplementation dazu, ist ein Multi-Milliarden Konzern und hat Resourcen ohne Ende.

Mono hat diesbezüglich weniger Unterstützung und Microsoft profitiert indirekt sogar noch davon dass ihr "Standard" ohne eigene finanzielle Aufwände auf andere Plattformen portiert wird.

Die Anzahl Avatare pro Simulator hat jedoch viel mehr mit der verwendeten Hardware zu tun als mit der Laufzeit Umgebung. Auf einem kleinen Server reine 32 Bit Installation laufen unter Mono etwa 30 Avatare. Unter .NET weiss ich es nicht, aber es könnnten möglicherweise mehr sein. Bei einer 64 bit Installation hatte ich nach 50 Avataren schlicht zu wenig Resourcen um weitere Roboter zu starten. Der Server ( EQ9 von Hetzner ) war jedenfalls mitnichten ausgelastet. Ueber den Daumen gepeilt hochgerechnet sollten etwa 300 Avatare möglich sein hab ich aber noch nicht getestet.

Ich habe in meinem OSgrid Leben so viele Sachen gesehen dass ich eine pauschal Aussage wie ".NET ist besser als MONO" schlicht nicht akzeptier. Eine wohlgepflegte .NET Umgebung verkraftet vielleicht etwas mehr Last als eine wohlgepflegte MONO Umgebung. Die Nuance ist im Wort "wohlgepflegt". Wer auf Windows zu Hause ist sollte sich nicht mit MONO rumschlagen. Umgekehrt werden Leute die Linux kennen sowieso auf MONO bleiben . Der Thread startete am 4. März 2010 und die Rede war von einer Version 0.6.6 aktuell ist aber 0.6.9 egal auf welcher Plattform 0.6.6 ist definitiv nicht mehr aktuell. Mit Mono 2.4.3 habe ich gute Erfahrungen gemacht. Mono 2.6.1 ebenfalls, Mono 2.6.3 hat ein Problem.
 

Users who are viewing this thread

Zurück
Oben Unten