Silberwelten Forum

Ich möchte einmal die Vorteile des FSAsset Speichers an einem Konkreten Beispiel aufzeigen. Bzw. den größten Vorteil.

Für meine Management Software habe ich am Wochenende eine weitere Auswertung geschrieben, die den Zustand der Assets darstellt. An dieser Auswertung sieht man den größten Vorteil des FSAsset sehr deutlich, der sonst eher im verborgenen bleibt.

Ein Bild sagt mehr als tausend Worte:


Der FSAsset speichert Assets, die einen identischen Inhalt haben, nur einmal physisch ab. Das bedeutet, wenn 20 mal die selbe Textur hochgeladen wird, haben wir 20 verschiedene Assets aber die Daten der Textur (die Textur selbst) wird trotzdem nur einmal abgespeichert.
Am obigen Bild kann man sehen, dass 160'000 Assets weniger gespeichert werden mussten (wegen dieser Deduplikation), was mir 12,5gb eingespart hat.

Auch das Assetwachstum kann man sehr gut beobachten. Vor allem auch, dass es bei häufigem Nutzen von OpenSim, fast linear ansteigt:


Ein weiterer Vorteil des FSAsset ist die Entlastung der Datenbank.


Wir können hier sehen, dass ich etwa 87gb Assets auf meinem Server habe, meine Datenbank aber nur 1gb Assetdaten enthält. (Bitte bedenken, dass HeidiSQL bei InnoDB Tabellen nur Näherungswerte des Inhalts anzeigt) Das sind lediglich die Metadaten der Assets. Dadurch werden die Datenbank DUmps deutlich kleiner und die Datenbank sowie ihre Backups werden entlastet.

Wenn ihr also ein Grid neu aufsetzt, denkt darüber nach, den FSAsset einzustellen.

Ich habe einen Eintrag dazu in der Robust.ini gefunden. Möglicherweise kann man hier eingiges konfigurieren:



Ist das richtig?

(28.03.2022, 15:22)Lukas schrieb: [ -> ]Ich habe einen Eintrag dazu in der Robust.ini gefunden. Möglicherweise kann man hier eingiges konfigurieren:

Code:

[AssetService]

    ;; Choose an asset service (Only one option should be enabled)
    LocalServiceModule = "OpenSim.Services.AssetService.dll:AssetService"
    ;LocalServiceModule = "OpenSim.Services.FSAssetService.dll:FSAssetConnector"

    ;; FSAsset Directories. Base directory, where final asset files are stored and Spool directory for temp files
    ;; These directories must be on the same physical filesystem
    ;BaseDirectory = "./fsassets/data"
    ;SpoolDirectory = "./fsassets/tmp"

    ;; Original service can be checked if FSAssets can not find an asset
    ;FallbackService = "OpenSim.Services.AssetService.dll:AssetService";

    ;; How many days since last updating the access time before its updated again by FSAssets when accessing an asset
    ;; Reduces DB calls if asset is requested often. Default value 0 will always update access time
    ;DaysBetweenAccessTimeUpdates = 30

    ;; Should FSAssets print read/write stats to the robust console, default is true
    ;ShowConsoleStats = true

    ;; FSAssets Custom Database Config (Leave blank to use grids default database configuration)
    ;StorageProvider = ""
    ;ConnectionString = ""
    ;Realm = "fsassets"

    ;; The following are common to both the default asset service and FSAsset service

    ;; Common asset service options
    DefaultAssetLoader = "OpenSim.Framework.AssetLoader.Filesystem.dll"
    AssetLoaderArgs = "./assets/AssetSets.xml"

    ; Allow maptile assets to remotely deleted by remote calls to the asset service.
    ; There is no harm in having this as false - it just means that historical maptile assets are not deleted.
    ; This only applies to maptiles served via the version 1 viewer mechanisms
    ; Default is false
    AllowRemoteDelete = false

    ; Allow all assets to be remotely deleted.
    ; Only set this to true if you are operating a grid where you control all calls to the asset service
    ; (where a necessary condition is that you control all simulators) and you need this for admin purposes.
    ; If set to true, AllowRemoteDelete = true is required as well.
    ; Default is false.
    AllowRemoteDeleteAllTypes = false

Ist das richtig?

Jap, das ist die richtige Stellen in der Config.

Deduplizierung ist in der Tat immer eine schöne Sache, wenn sie denn gut funktioniert und vor allem performant ist.

Der Hauptvorteil von FSAsset aber liegt in einem anderen Bereich, und zwar der besseren Leistung.

Wenn Assets als BLOBs in einer Datenbank gespeichert werden, dann erzeugt dies ziemlich viel Komplexität, wenn ein Asset vom Server angefordert wird, weil:

1. es kommt die Anfrage per TCP/IP oder Socket
2. die Datenbank muss die SQL-Anfrage bearbeitet werden
3. dann muss das Asset gefunden werden, d.h. erneut Suche in der Datenbank und Zugriff auf das Filesystem
4. Dann wird das an den Server geliefert
5. Der Server liefert es an den Client

Die Probleme daran sind, dass die meisten Datenbanken einfach nicht dafür gedacht sind und daher absolut unoptimiert, um ein großer BLOB-Storage zu sein. Auch macht es die Backups der Datenbank sehr schnell und sehr groß, ebenso hat es Einfluss auf die Replikation. Weil die Datenbank sehr viel bei der Auslieferung des Assets beteiligt ist, durchläuft damit eine Anfrage auch hier mehrere Bereiche, also TCP/IP-Stack des Betriebssystem, sehr viel Datenbank und dann noch Dateisystem.

Wenn dagegen das BLOB auf dem Dateisystem direkt angelegt ist - das ist genau FSAsset - und in der Datenbank nur der Dateipfad gespeichert wird, dann wird es einfach deswegen deutlich schneller geladen, da zum Bekommen der Daten nicht mehr das komplette Datenbanksystem mit all seiner Komplexität bemüht werden muss, sondern statt dessen direkt das Betriebssystem mit seinem Dateisystem. Und das ist dann nunmal deutlich schneller.

Es gibt dazu auch ein Paper namens "To blob or not to blob" von Microsoft aus dem Jahr 2006, das einfach zu lesen ist und 11 Seiten hat. Dort wird BLOB-Storage in einem SQL-Server von der Performance her mit reinem Dateissystem (NTFS) verglichen. Die wesentliche Aussage ist, dass damals bis 256 KB Dateisystemgröße die Datenbank schneller arbeitet, ab 1 MB aber das Dateisystem. Sicher ist jedenfalls, wenn man eine Menge an Daten hat dann ist das Dateisystem fast immer gegenüber einer SQL-RDBMS besser.

Interessanterweise ist die Datenbank unter Umständen schneller als das Dateisystem, welches auch wieder nur eine Datenbank ist:

https://people.apache.org/~dongsheng/hor...arison.pdf

Datenbanken sind darauf ausgelegt sehr schnelle Zugriffe auf Daten zu realisieren. Die Sockets sind unter localhost zu vernachlässigen. Hier begrenzt nur die CPU die Übertragungsgeschwindigkeit.

Nun ja, der Kontext "Datenbank" in dem wir uns hier gerade bewegen bedeutet eben AKID-Konformität, also Atomarität, Konsistenzerhaltung, Isolation und Dauerhaftigkeit.

Für die Sicherstellung dieser Eigenschaften in einem RDBMS wie Postgres oder MySQL braucht es eben einigen Aufwand. Ein Dateisystem erfüllt normalerweise nicht all diese Eigenschaften gleichzeitig, daher braucht es weniger Rechenleistung und das ist dann oft von Vorteil.

Und bei Dateisystemen an sich gibt es ja gewaltige Unterschiede zwischen denselben, also Eigenschaften und Geschwindigkeit. Käme ich beispielsweise mit FAT auf die Idee, > 10000 Dateien in einen Ordner zu kippen wird das doch schon sehr grenzwertig.

Modernere Systeme wie ext4 oder NTFS haben damit eben weniger Probleme. Ganz interessant finde ich ja die COW-Systeme, wobei da ZFS ganz klar am ausgereiftesten ist.

Aber remote Backups mit ZFS ist wirklich MWAH - zuerst einen Snapshot machen, dann zfs send von dem, Snapshot weg und das wars.

Hallo Ihr Beiden!

Also im Hinblick auf die Performance sehe ich aber für das FSAsset nicht grundsätzlich einen Performance-Vorteil, wenn ich mir Eure beiden Dokumente ansehe.

A) https://www.microsoft.com/en-us/research...ilesystem/
B) https://people.apache.org/~dongsheng/hor...arison.pdf

In dem ersten Dokument geht es um Windows und dem SQL Server, im zweiten Dokument geht es um Linux und MySQL. Im Ersteren hat das Dateisystem einen Vorteil bei grösseren Dateien >=1MB, und beim Zweiten hat die Datenbank bei größeren Dateien die Nase vorn. Dabei fiel mir ein Servertest ein, den es mal vor längerer Zeit in der ct von Heise gab. In diesem Test wurden Windowsserver und Linuxserver getestet (ich habe leider diese Tests im Internet nicht wiedergefunden). Soweit ich mich erinnere gab es keinen Testsieger. Was aber bei dem Test herauskam war, daß die Filesysteme der unterschiedlichen Betriebssysteme, in einem Fall auf grössere Dateien und im anderen Fall auf kleinere Dateien optimiert waren. Die Daten in Euren beiden Dokumenten sprechen dafür, daß das Windows NTFS auf grössere Dateien und das Linux ext? auf kleinere Dateien optimiert ist.

Schauen wir uns mal die Daten im Dokument B an. Dort wurde MySQL unter Linux getestet. Es gab 2 Testreihen einmal mit kleineren und einmal mit grösseren Dateien. Die Tests innerhalb einer Testreihen wurden 2mal wiederholt um Caching-Einflüsse mit zu erfassen. Im Bild 1 beim ersten Dateizugriff gibt es einen deutlichen Unterschied zwischen Filesystem und Datenbank. Ab dem 2. Zugriff mit Caching Einfluss sind dann aber Filesystem und Datenbank gleichwertig. Im fortgesetzten Betrieb ist der Zugriff mit Caching-Einfluss der Normalfall, der erste Zugriff ist ein einmaliger Sonderfall. Im Bild 2 hat deutlich die Datenbank die Nase vorn. Ergo, das FSAsset bringt auf einem Linuxserver keinen Performancevorteil.

Zum Dokument A muss ich sagen: Da ich beim Linuxserver meine Antwort hatte, hab ich nur die Schlussfolgerungen gelesen. 

"The study indicates that if objects are larger than
one megabyte on average, NTFS has a clear advantage
over SQL Server. If the objects are under 256
kilobytes, the database has a clear advantage."

Demnach hat das FSAsset auf einem Windowsserver einen Performancevorteil, wenn die BLOB-Daten >=1MB sind. Dazu wie sich diese Datengrösse real verhält, habe ich aber keine Daten, so daß ich hier keine eindeutige Schlussfolgerung ziehen kann.

Den Vorteil den ich sehe, ist der den Kubwa oben durch die Deduplikation anführte, durch den man Speicherplatz spart, sich bei grossen Dateien auf einem Linux Server aber Performancenachteile einhandelt. Habe ich das richtig verstanden das es diese Deduplikation bei der Speicherung in der Datenbank nicht gibt? Oder ist das nur eine Konfigurationsfrage?

Sicher, wie immer im Leben gibt es für alles seine Einsatzzwecke. Ich bin der Meinung, wenn es nur eine kleine Sim ist und da nicht viel los ist, wird sich FSAsset mit MySQL nicht viel geben. Wenn man dagegen aber viele Assets hat wie Kubwa, und vielleicht auch noch viel los auf der Sim sieht es dann schon sicher anders aus, da bin ich mir ziemlich sicher dass es schon spürbare Unterschiede gibt. Vermutlich wird man die Unterschiede besonders dann richtig spüren, wenn man den Assetserver für ein mittleres Grid betreibt mit einigermaßen Auslastung, denn wenn ich mich noch richtig erinnere ist genau wegen dieses Einsatzzwecks FSasset geschrieben worden weil es ab da eben mit MySQL schwierig wurde.

Aus Backupgründen ist mir FSAsset aber lieber; dann müllen die Assets nicht mein MySQL-Backup zu. Auch werden die MySQL-Backups dadurch wesentlich kleiner.

Zu dem Thema schrieb 2006 mal der bekannte Tech-Autor Kris Köhntopp einen Blogpost. Es ging dabei aber um den Einsatzzweck, dass auf einer einfachen Webseite ein Bild angezeigt werden soll. Also verglich er aus Sicht des Eingangs beim Server die Komplexität von LAMP mit Bild liegt direkt im Dateisystem und wird dann statisch vom Webserver ausgeliefert.

Der Link dazu ist hier; auch wenn da natürlich gewisse Bereiche bei Opensimulator wegfallen, so ist es doch in gewisser Weise vergleichbar. Köhntopp arbeitete übrigens damals für MySQL AB, also der wusste durchaus wovon er sprach.

http://mysqldump.azundris.com/archives/3...abase.html

Am Besten drückt es dort finde ich der folgende Kommentar aus: "In the end, the filesystem is always the best container for information you don't plan on changing a lot. Leave the database to hold DATA." Und Assets in Opensim ändern sich nicht; sie sind entweder da, oder sie sind gelöscht. Aber ein Asset wird nicht unter derselben UUID aktualisiert.

Also, ich habe mal etwas im Internet recherchiert. Die Vorgehensweise BLOB-Daten im Dateisystem und nur Links darauf in die Datenbank zu speichern, scheint unabhängig vom verwendeten Betriebssystem allgemein üblich zu sein. Was mich nur im Moment stört, daß das sich scheinbar mit den Messergebnissen in Kubwas Dokument beißt. Die Zahlen dort sprechen eine andere Sprache, und diesen Widerspruch möchte ich gern auflösen.

https://people.apache.org/~dongsheng/hor...arison.pdf

Es muss einen Grund für diesen Widerspruch zwischen Messergebnis und praktischer Erfahrung geben. Ich denke ich habe auch etwas gefunden was dafür verantwortlich sein könnte. Die Abfragegeschwindigkeit der Datenbank sinkt mit wachsender Grösse. Ich vermute der Test in Kubwas Dokument wurde sicher mit einer frisch aufgesetzten kleinen Datenbank durchgeführt.

https://use-the-index-luke.com/de/sql/te...datenmenge

Dem Effekt wirkt FSAsset natürlich entgegen. Durch das externe Speichern der BLOB-Daten wird die Datenbank klein gehalten, und deren Abfragegeschwindigkeit sinkt nicht oder nicht so stark ab. Wenn ich das alles zusammenfassen komme ich zu 2 Anwendungsszenarien:

1) Kleines Grid in dem nur die eigene Familie oder einige wenige Freunde aktiv sind. In so einem Gird spielt es keine Rolle ob FSAsset verwendet wird oder nicht. Oder es ist ja nach Datenbankgrösse sogar etwas von Vorteil, es nicht zu tun, da hier die Messergebnisse aus Kubwas Dokument zum tragen kommen.

2) Mittleres bis grosses Grid bei dem die Datenbank auf alle Fälle Grössen erreicht, bei der die Abfragegeschwindigkeit stark absinken würde. Strebt man so ein Grid an, sollte FSAsset verwendet werden.

Schön wäre es wenn man das noch mit Beispielen in Form von existierenden Grids belegen könnte. Das OSGrid kann man sicher als grosses Grid klassifizieren. Aber was geht als kleines Grid durch? Trifft das zum Beispiel noch auf das Swissgrid oder das Carima-Grid zu?

https://swissgrid.opensim.ch/index.php/de/
http://carima-welt.de:8002/

Beide Dokumente sind sehr alt. Kubwas allerdings erwähnt eine Vielzahl an Parametern nicht, die die Performanz beeinflussen können. Es ist mehr die Skizze einer wissenschaftlichen Veröffentlichung als eine wissenschaftlichen Veröffentlichung. Vieles kann man nur raten, wie z.B. welches Dateisystem wurde eingesetzt?

Der Artikel von Microsoft ist fundierter, und legt die Methodik deutlich genauer und nachvollziehbarer nach.

Wenn man Assets in einer Datenbank speichert, dann macht es die Backups einfach unnötigerweise platzfressend. Eine Datenbank wird ja normal als Dump gespeichert, d.h. vollständiges Schreiben aller Inhalte auf dem Dateisystem. Wenn einigermaßen was los ist auf der Sim/Grid, dann täglich ein Dump.

Diesen Dump kann man, wenn überhaupt, nur schwer deduplizieren. Da braucht man schon Dateisysteme wie ZFS, und der Prozess ist bekannt dafür, dass wenn er läuft viel Speicher braucht - pro TB Plattenplatz im Dateisystem 5 GB RAM plus.

Auch wenn man Offsite-Backups macht, dann muss man jedesmal (sofern man nicht sowas wie zfs send nutzt) die komplette Datei übertragen. Und inkrementell wird auch schwer.

Also für Eigengebrauch/Heimsim ja, kann man Datenbank sicher nutzen. Wenn man aber sich so richtig in Opensim austoben will, werden die diversen Vorteile FSAsset sicherlich sehr schnell deutlich überwiegen.