Anym001 Posted March 12, 2021 Share Posted March 12, 2021 Hallo, mir ist aufgefallen, dass die RAM Auslastung nach dem Update auf 6.9.1 deutlich erhöht ist. 6.9.0 -> ca. 28% 6.9.1 -> ca. 38% ASRock J4105-ITX 8GB DDR4 Habt ihr das Phänomen auch? Ist das normal? Kann man irgendwie nachprüfen was diese Erhöhung verursacht? Quote Link to comment
mgutt Posted March 12, 2021 Share Posted March 12, 2021 Das in beiden Versionen ausführen und vergleichen: ps -e -o pid,vsz,comm= | sort -n -k 2 Von hier: https://superuser.com/a/398870/129262 Quote Link to comment
Anym001 Posted March 14, 2021 Author Share Posted March 14, 2021 Vielen Dank erstmal. Habe ursprünglich von 6.9.0 auf 6.9.1 upgedated, ohne das ich Docker gestoppt oder deaktiviert habe. Danach wieder mithilfe von Restore zurück auf 6.9.0. Hier dann deinen Befehl ausgeführt. Heute habe ich dann abermals 6.9.0 auf 6.9.1 upgedated, aber diesmal alle Docker Container gestoppt. Hier dann wieder deinen Befehl ausgeführt. Eine Gegenüberstellung ist in der angehängten Datei. Leider kann ich das nicht interpretieren. Hoffe du kannst mir da weiterhelfen. Kann es sein, dass Docker Images mehrfach aufgerufen werden? (Gewisse EInträge findet man mehrmals in der Auflistung) file.ods Quote Link to comment
mgutt Posted March 14, 2021 Share Posted March 14, 2021 Müsste man am besten nach Prozessname summieren. Der erste Wert ist die RAM Nutzung in Bytes. Kann ich gerade nicht. Eventuell die Tage. Quote Link to comment
Anym001 Posted March 15, 2021 Author Share Posted March 15, 2021 Anbei die Datei mit den summierten Werten. :) file.ods Mir ist aufgefallen, dass ich nach dem Restore von 6.9.1 auf 6.9.0 auch in 6.9.0 einen erhöhten RAM Wert hatte. Quote Link to comment
mgutt Posted March 15, 2021 Share Posted March 15, 2021 Mir ist gerade aufgefallen, dass der erste Wert die pid ist und nicht die RAM-Auslastung. Außerdem sind es KiB und nicht Bytes. Ich habe die Tabelle nun mal in MiB umgerechnet und entsprechend sortiert: Diese Differenz ist aber weit entfernt von den 10%, die du im 1. Beitrag beschrieben hast. Warum belegt Jellyfin eigentlich so viel? ram-auslastung.ods Quote Link to comment
mgutt Posted March 15, 2021 Share Posted March 15, 2021 Ich habe auch mal bei mir verglichen. Es scheint, dass der vsz Wert von ps nicht wirklich den genutzten RAM widerspiegelt: Denn ich habe von 64GB nur 9% belegt, was 5,76 GB entspricht und nicht ~14 GB wie im Screenshot zu sehen. Mal sehen was vsz wirklich bedeutet. EDIT: Ok, es scheint wir brauchen "Resident Size": https://stackoverflow.com/a/561450/318765 Quote Link to comment
Anym001 Posted March 15, 2021 Author Share Posted March 15, 2021 36 minutes ago, mgutt said: Diese Differenz ist aber weit entfernt von den 10%, die du im 1. Beitrag beschrieben hast. Ich weiß. Leider konnte ich den Wert nicht mehr darstellen, weil nachdem ich von 6.9.1 wieder auf 6.9.0 zurück gegangen bin, war der Verbrauch ähnlich hoch. 38 minutes ago, mgutt said: Warum belegt Jellyfin eigentlich so viel? Puh keine Ahnung. Das weiß ich leider nicht. 36 minutes ago, mgutt said: EDIT: Ok, es scheint wir brauchen "Resident Size": https://stackoverflow.com/a/561450/318765 Was genau meinst du damit? Quote Link to comment
mgutt Posted March 15, 2021 Share Posted March 15, 2021 24 minutes ago, Anym001 said: Was genau meinst du damit? Es gibt zwei Messmethoden. VSZ und RSS. Laut der Liste hast du 50 GB belegt. Ich denke nicht, dass das stimmt. Daher sollten wir mal versuchen RSS auszuwerten. Quote Link to comment
mgutt Posted March 15, 2021 Share Posted March 15, 2021 Ich habe es mal mit einem anderen Weg versucht. Über das Nerd Pack habe ich "atop" installiert und dann ausgeführt. Drückt man "p" wird nach Programm zusammengefasst: Meine Auswertung bringt allerdings als rsize das raus was ps als vsz zurückgeliefert hat. Schon bekloppt: Und ~14 GB sind wie gehabt noch deutlich mehr als 5,76 GB, die wirklich belegt sind laut Dashboard. Ich habe dann mit dem Kommando die RAM-Auslastung geprüft: free -m -h Ergebnis: total used free shared buff/cache available Mem: 62Gi 3.5Gi 14Gi 1.4Gi 44Gi 57Gi Swap: 0B 0B 0B vs: Wie kommt Unraid nun auf 9%?! thoth-ram-usage-atop.ods Quote Link to comment
Peddarson Posted March 15, 2021 Share Posted March 15, 2021 1 hour ago, mgutt said: Wie kommt Unraid nun auf 9%?! Ganz einfach: laut der Anzeige sind noch 57gb von 62gb verfügbar (ohne cache). Ergo sind sehr grob gerundet nur 9% belegt. Sind laut meiner Rechnung sogar nur 8%. 1 Quote Link to comment
Anym001 Posted March 16, 2021 Author Share Posted March 16, 2021 Folgendes Ergebnis bei mir: 7,4 - 4,8 = 2,6 100 / 7,4 * 2,6 = 35,14 % Wirklich interessant, dass Jellyfin so viel braucht. Auch apache2 ist ziemlich hoch. (Schätze mal das ist Nextcloud) Powertop kann ja damit nichts zu tun haben oder? Quote Link to comment
mgutt Posted March 16, 2021 Share Posted March 16, 2021 Ich vermute, dass es nichts mit Unraid, sondern mit Jellyfin zu tun hat: https://www.reddit.com/r/jellyfin/comments/m52zuv/holy_memory_usage_batman/?utm_source=amp&utm_medium=&utm_content=post_body Dort wird gesagt, dass eine Swap Partition helfen sollte. Hast du eine SSD? Dann könnte man darauf eine Swap-Datei erstellen. Zb 32GB. Linux legt dort dann "veraltete" Daten aus dem RAM ab. Quote Link to comment
Anym001 Posted March 16, 2021 Author Share Posted March 16, 2021 Habe jetzt mal in Jellyfin die automatische Bibliothek Synchronisierung deaktiviert. War zuerst kurze Zeit schon mal auf 39% Auslastung und ~700M durch Jellyfin. Durch die Deaktivierung bin ich jetzt auf 33%. 6 minutes ago, mgutt said: Hast du eine SSD? Dann könnte man darauf eine Swap-Datei erstellen. Ja habe ich. Wie würde man so etwas machen? Eine Swap-Datei würde ja allgemein den RAM entlasten oder? Oder sollte ich das Ganze einfach ignorieren? Quote Link to comment
mgutt Posted March 16, 2021 Share Posted March 16, 2021 2 hours ago, Anym001 said: Folgendes Ergebnis bei mir: Hatte ich vergessen zu sagen. Du musst "M" drücken und dann "P". So wird die Anzeige nach RAM sortiert und dann nach Programm summiert. Wenn du "L" drückst und dann jede Frage mit zB "20" beantwortest, zeigt er auch alle CPU Kerne und Disks im oberen Bereich. Aktuell läuft bei mir ein Parity Check und das ergibt das: 6 minutes ago, Anym001 said: Eine Swap-Datei würde ja allgemein den RAM entlasten oder? Nein. Swap ist nur dafür da veraltete Informationen aus dem RAM zu werfen oder falls der RAM nicht mehr reicht auf den Swap auszuweichen. Du kannst ja mal den Swap für eine Woche oder so aktiv lassen: https://forums.unraid.net/topic/104213-swap-creator/ Wenn es nichts bringt, dann mit "swapoff -a" einfach wieder deaktivieren und per "rm /mnt/cache/swapfile" löschen. Quote Link to comment
Anym001 Posted March 16, 2021 Author Share Posted March 16, 2021 (edited) 40 minutes ago, mgutt said: Hatte ich vergessen zu sagen. Du musst "M" drücken und dann "P". So wird die Anzeige nach RAM sortiert und dann nach Programm summiert. Wenn du "L" drückst und dann jede Frage mit zB "20" beantwortest, zeigt er auch alle CPU Kerne und Disks im oberen Bereich. Aktuell läuft bei mir ein Parity Check und das ergibt das: Nun folgendes Ergebnis: 40 minutes ago, mgutt said: Du kannst ja mal den Swap für eine Woche oder so aktiv lassen: Werde ich mal ausprobieren und dann berichten ob sich was verändert hat. Vielen Dank auf jeden Fall schon mal für deine Bemühungen. EDIT: Erhalte im Syslog folgende Warnung. Kann ich die ignorieren? Mar 16 11:01:17 nas kernel: BTRFS warning (device sdb1): swapfile must not be copy-on-write Edited March 16, 2021 by Anym001 Quote Link to comment
ich777 Posted March 16, 2021 Share Posted March 16, 2021 16 hours ago, Anym001 said: Ich weiß. Leider konnte ich den Wert nicht mehr darstellen, weil nachdem ich von 6.9.1 wieder auf 6.9.0 zurück gegangen bin, war der Verbrauch ähnlich hoch. Dann hast du deine Antwort, nicht Unraid sondern ein Container macht das... Wenn ich mir deine Screenshots so ansehe dann belegt dein Jellyfin container gerade 335,1MB hält sich doch in grenzen... Mein Emby server belegt auch ca. 380MB On 3/12/2021 at 7:37 AM, mgutt said: ps -e -o pid,vsz,comm= | sort -n -k 2 Wäre hier nicht "ps -e -o pid,rss,comm= | sort -n -k 2" besser geeignet da dies den reellen Speicherbedarf spiegelt und nicht den "virtuellen"? Quote Link to comment
mgutt Posted March 16, 2021 Share Posted March 16, 2021 1 hour ago, ich777 said: belegt dein Jellyfin container gerade 335,1MB Ja aber was verursacht dann die 36%, die er im Dashboard sieht? Also grob 3GB in Summe. Quote Link to comment
Anym001 Posted March 16, 2021 Author Share Posted March 16, 2021 5 hours ago, mgutt said: https://forums.unraid.net/topic/104213-swap-creator/ Also dein Script hat erfolgreich ein Swapfile unter /mnt/cache/swapfile erstellt. Quote free -m -h Jedoch leider keine Swapkapazität ersichtlich. Quote swapon /mnt/cache/swapfile Die manuelle Aktivierung des Swaps bringt folgende Fehlermeldung. Quote Link to comment
mgutt Posted March 16, 2021 Share Posted March 16, 2021 5 hours ago, Anym001 said: Mar 16 11:01:17 nas kernel: BTRFS warning (device sdb1): swapfile must not be copy-on-write Das ist der Grund. BTRFS wird scheinbar nicht unterstützt. Dumm gelaufen 😩 Quote Link to comment
mgutt Posted March 16, 2021 Share Posted March 16, 2021 Ich habe mir jetzt mal das Script geladen und ausgeführt: /tmp/user.scripts/tmpScripts/ps_mem/script Private + Shared = RAM used Program 20.0 KiB + 0.5 KiB = 20.5 KiB s6-svscan 32.0 KiB + 1.0 KiB = 33.0 KiB s6-supervise (2) 112.0 KiB + 34.5 KiB = 146.5 KiB sleep 128.0 KiB + 38.5 KiB = 166.5 KiB inetd 156.0 KiB + 42.5 KiB = 198.5 KiB init 168.0 KiB + 34.5 KiB = 202.5 KiB crond 148.0 KiB + 55.5 KiB = 203.5 KiB avahi-dnsconfd 180.0 KiB + 32.5 KiB = 212.5 KiB acpid 180.0 KiB + 45.5 KiB = 225.5 KiB wsdd 132.0 KiB + 117.0 KiB = 249.0 KiB atd (2) 316.0 KiB + 123.5 KiB = 439.5 KiB rpcbind 268.0 KiB + 194.5 KiB = 462.5 KiB diskload 516.0 KiB + 49.5 KiB = 565.5 KiB apcupsd 496.0 KiB + 114.5 KiB = 610.5 KiB dbus-daemon 488.0 KiB + 391.0 KiB = 879.0 KiB sh (2) 780.0 KiB + 299.0 KiB = 1.1 MiB agetty (6) 856.0 KiB + 411.5 KiB = 1.2 MiB EasyAudioEncoder 1.2 MiB + 63.5 KiB = 1.3 MiB rsyslogd 820.0 KiB + 606.0 KiB = 1.4 MiB avahi-daemon (2) 1.3 MiB + 382.5 KiB = 1.6 MiB emhttpd 1.7 MiB + 51.5 KiB = 1.8 MiB udevd 1.7 MiB + 300.5 KiB = 2.0 MiB ntpd 1.4 MiB + 654.5 KiB = 2.1 MiB virtlogd 1.4 MiB + 756.5 KiB = 2.1 MiB virtlockd 1.9 MiB + 412.5 KiB = 2.3 MiB ttyd 2.5 MiB + 386.5 KiB = 2.9 MiB nmbd 2.4 MiB + 1.0 MiB = 3.3 MiB bash (4) 2.0 MiB + 1.5 MiB = 3.5 MiB Plex Tuner Service 4.1 MiB + 132.5 KiB = 4.2 MiB rpc.statd 2.8 MiB + 4.0 MiB = 6.8 MiB nginx (2) 9.3 MiB + 0.5 KiB = 9.3 MiB containerd-shim 5.3 MiB + 7.7 MiB = 13.0 MiB smbd (4) 13.2 MiB + 0.5 KiB = 13.2 MiB unbalance 11.5 MiB + 1.9 MiB = 13.4 MiB libvirtd 12.4 MiB + 3.1 MiB = 15.5 MiB startBackground 9.3 MiB + 7.4 MiB = 16.6 MiB winbindd (4) 12.0 MiB + 9.6 MiB = 21.6 MiB php-fpm (4) 32.9 MiB + 1.8 MiB = 34.7 MiB docker-proxy (9) 35.9 MiB + 0.5 KiB = 35.9 MiB containerd 67.6 MiB + 0.5 KiB = 67.6 MiB dockerd 118.5 MiB + 1.3 MiB = 119.8 MiB Plex Script Host 273.5 MiB + 603.0 KiB = 274.1 MiB shfs (2) 651.0 MiB + 0.5 KiB = 651.0 MiB rcloneorig 657.0 MiB + 2.0 MiB = 659.0 MiB Plex Media Server --------------------------------- 1.9 GiB ================================= Dazu noch mal die RAM-Nutzung: free -m -h total used free shared buff/cache available Mem: 62Gi 4.1Gi 5.0Gi 1.4Gi 53Gi 56Gi Swap: 15Gi 0B 15Gi Also ich check's nicht ^^ Wo ist denn die Differenz zwischen 4,1GB used und den ermittelten 1,9GB? Quote Link to comment
Anym001 Posted March 17, 2021 Author Share Posted March 17, 2021 14 hours ago, mgutt said: Das ist der Grund. BTRFS wird scheinbar nicht unterstützt. Dumm gelaufen 😩 Okay schade. :/ Allerdings gut zu wissen. Hab`s jetzt wieder deaktiviert. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.