Leider findet man quasi gar keine Benchmarks, wenn jemand RAM verbaut. Den einzigen, den ich weltweit mit Benchmarks finden konnte ist dieser:
https://techtest.org/synology-ram-aufruesten-was-bringt-es-synology-ds1817/
Es gibt zwar weitere positive Erfahrungsberichte, aber nur subjektiv beschrieben und wer vorher nur 1 oder 2GB hatte, der wird logischerweise was merken, wenn er mehr RAM verbaut. Viel interessanter ist aber ob man von sagen wir mal 8 auf 32 GB noch was erreichen kann.
Standardmäßig denke nicht, denn wenn auch Linux gerne jeden freien RAM zum Caching nutzt (
https://www.linuxatemyram.com/ ), so fehlt da die Intelligenz, die Synology beim SSD Cache nutzt. Nämlich über einen längeren Zeitraum auszuwerten welche Dateien eigentlich so heiß sind, dass sie dauerhaft im Cache verbleiben sollten. Also so wie ein klassischer File-Cache eigentlich funktionieren sollte. Daher mutmaße ich, dass von 2 auf 4 oder 8GB ein großer Sprung spürbar ist, aber danach quasi nichts mehr kommt, außer man nutzt den RAM aktiv. Also zB für VMs, MySQL, etc.
Allerdings habe ich hier etwas Interessantes gefunden:
https://forums.plex.tv/t/tip-decrease-poster-load-times/186895
How to
SSH to your Plex machine
Download and compile vmtouch as described in the link above.(it is easy)
Determine the path to your Metadata folder.
cd /Your-Path/Plex Media Server/Metadata/
run: du-h (to see how much data you have in your Metadata folder)
If the total size is lower then 50%-60% of your total RAM capacity, go to step 7. Else, go buy some RAM.
run: vmtouch -dl “/Your-Path/Plex Media Server/Metadata/”
Now wait for vmtouch to read the content of your metadata folder. You can monitor this using htop.
When vmtouch RAM usage has stop increasing, you can test out and see if loading times have decreased.
On my setup, it made quite a big difference.
While browsing my movie library via Plex Web or the Samsung Plex App, the posters load much much faster.
My Metadata folder is ~ 10 GB
My RAM capacity is 32 GB
Sucht man im Netz nach "synology vmtouch", dann stellt man auch fest, dass Synology das Paket bereits vorinstalliert hat und es selbst für solche Befehle nutzt:
/usr/bin/vmtouch -lfd /var/run
/usr/syno/bin/vmtouch -lfd /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/network-scripts/ifcfg-tun /etc/sysconfig/network-scripts/ifcfg-tun1000
lfd steht dabei für:
l = Datei im RAM locken
f = symbolischen Links folgen
d = im Hintergund als Daemon laufen lassen
Hier gibt es auch ein paar Infos:
https://serverfault.com/q/43383/44086
Die Frage ist dann nur noch wie man evtl automatisiert herausfindet, welche Dateien heiß sind und man mit einem selbst definierten Ziel von zB 50% des RAMs vmtouch ständig arbeiten lässt. Der SSD Ratgeber von DSM wertet das zB per synoscgi_SYNO.Storage.CGI.Flashcache_1_statistics aus. Soweit ich das sehe, ist das Skript aber relativ "dumm". Sie nehmen von jedem Tag das letzte Aufrufdatum der Dateien, summieren die Dateigrößen dieser Dateien der letzten Woche und alle Dateien, die davor aufgerufen wurden sind die kalten Dateien. Das muss tatsächlich so dumm sein, denn mein NAS ist frisch aufgesetzt und bei mir sind 1 TB heiß, 8TB warm und nur 200 GB kalt. Eben weil ich erst vor kurzem alle Dateien frisch auf das NAS kopiert habe.
Man könnte ein ähnliches Prinzip auch mit vmtouch umsetzen, allerdings weiß ich nicht ob das last access Datum der Dateien überhaupt noch geschrieben werden, wenn die Dateien direkt aus dem RAM kommen. Vielleicht weiß das ja jemand. Wenn sich die Datei ändert, dann bekommt vmtouch das auf jeden Fall selbst nicht mit:
https://github.com/hoytech/vmtouch/issues/39
Man muss also bei Änderungen den Cache immer killen und neu aufbauen lassen. Aus dem Grund ist vermutlich das manuelle Cachen von bestimmten Verzeichnissen wie oben genannte Plex Thumbnails am besten.
