Ruckeln - Speicherverwaltung des Kernels optimieren

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ruckeln - Speicherverwaltung des Kernels optimieren

    Ich habe mit folgenden Kernelparameter wirklich gute Ergebnisse.
    Keine Ruckler bei irgendetwas auch ohne den Einsatz von clearmemlite.

    Das Thema ist eigentlich auch nicht Gigablue spezifisch sondern eher allgemein.
    Ich hab es trotzdem mal hier aufgemacht, da Gigablue Besitzer oftmals von Rucklern besonders bei Wiedergabe von Aufnahmen berichten.

    Es wäre gut, wenn einige Anwender und natürlich auch die Entwickler das ebenfalls testen und bei positiven Test dann auch in die Images einfließen lassen könnten.

    Man muss nur in der Datei /etc/sysctl.conf folgende Werte setzen.

    vm.min_free_kbytes = 131072
    vm.swappiness = 0
    vm.vfs_cache_pressure = 200

    Die ersten beiden Einstellungen existieren schon, dort nur die Werte anpassen.
    Die 3. Zeile neu hinzufügen.
    Danach die Box neu booten und falls ihr es im Einsatz habt nicht vergessen clearmemlite deaktivieren.

    Aus meiner Sicht arbeitet die Memoryverwaltung des Kernels danach viel besser für unseren Anwendungfälle.
    Bitte probiert das doch einfach mal aus und gebt Rückmeldung.
    2 x Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
  • redzoro schrieb:

    Die ersten beiden Einstellungen existieren schon, dort nur die Werte anpassen.
    Bei der HD51 z.B. gibt es keinen dieser Werte.
    Das pauschal auf jeder Box zu nutzen wird bestimmt keine optimalen Ergebnisse bringen.
    Bei der Quad4k stimmt deine Aussage.
    Meine Bastelboxen: Mut@nt HD51 | GB Quad 4K | Mut@nt HD60 | OSMIO4K | HIS 4k Combo+

    ... Keinen Support per PN ... bitte stellt eure Fragen ins Forum!...

    ~ Benutzung OpenHDF Image ~ Benutzung der HDF-Toolbox ~ FAQ und Linksammlung ~ Build und Foren Server Spendenaktion ~
  • Bei meiner Quad 4K sieht es defaultmäßig so aus:

    vm.min_free_kbytes=8192
    vm.swappiness = 30
    vm.vfs_cache_pressure = 100

    Die Ruckler-Problematik hat meine Quad 4K nicht (noch nie gehabt).
    (Deswegen auch kein clearmemlite im Einsatz)
    Ich probiere die neuen Werte trotzdem aus, um zu sehen ob sich nicht doch eine
    zusätzliche, positive Änderung der Verhaltensweise ergibt.
    Wobei ich die komplette Abschaltung des Swap-Mechanismus (vm.swappiness=0)
    für kontraproduktiv halte, da man im Falle akuter Speicherknappheit gar nicht mehr
    (oder nur mit sehr langen Wartezeiten) ans System kommt, um etwas ändern zu können.
    Da helfen dann auch wesentlich höhere Werte von vm.vfs_cache_pressure nicht.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von cricriat ()

  • swappiness = 0 heißt nicht das gar nicht geswapped wird.
    Der Kernel swapped dann, wenn kein RAM mehr verfügbar ist und nicht schon vorher.
    Im Notfall wenn alles Memory aufgebraucht ist macht er es trotzdem. Nur nicht schon früher, wo es nicht gewünscht ist. Wir betreiben eine ganze Menge professioneller Linux Server mit swappiness = 0 um genau diese frühe und bei zeitkritischen Anwendungen unerwünschte swappen zu verhindern.
    Natürlich gibt es auch Anwendungsfälle wo man swapping möchte.
    Wenn ich auf einem Server 100 oder mehr VM mit vor sich hin schlafenden Webservern betreiben will, möchte ich ja vielleicht nicht allen Servern statisches RAM zuweisen. Dann ist es unter Umständen beabsichtigt nicht aktive Teile im Swap zu haben.
    Auf unseren Boxen sehe ich das aber nicht.
    2 x Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
  • Koivo schrieb:

    redzoro schrieb:

    Die ersten beiden Einstellungen existieren schon, dort nur die Werte anpassen.
    Bei der HD51 z.B. gibt es keinen dieser Werte.
    Das pauschal auf jeder Box zu nutzen wird bestimmt keine optimalen Ergebnisse bringen.
    Bei der Quad4k stimmt deine Aussage.


    Hi Koivo,
    Ich bin mir auch nicht sicher, ob das auf allen Boxen hilfreich ist.
    Eigentlich denke ich schon, aber wer weiß.
    Ich hab es auch auf der Octagon Sf8008 gemacht und auch dort nur Vorteile gesehen.
    Es ist für unser Anwendungsfach einfach unglücklich alles Memory in Caches und Buffer zu packen, die eh hier nicht wirklich was bringen hier und erst ganz spät zu reorganisieren. Das ist mit diesen Parametern besser.

    Ob aber auf allen Boxen nur Verbesserungen erzielt werden?

    Ich denke, da hilft nur ausprobieren und testen.
    2 x Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
  • redzoro schrieb:

    swappiness = 0 heißt nicht das gar nicht geswapped wird.


    Hier steht etwas anderes:
    linuxhint.com/understanding_vm_swappiness/

    Auszug:
    Changing the value directly influences the performance of the Linux system. These values are defined:
    * 0: swap is disabled
    * 1: minimum amount of swapping without disabling it entirely
    * 10: recommended value to improve performance when sufficient memory exists in a system
    * 100: aggressive swapping

    Es gibt noch andere Seiten, die ähnliches bzw. gleiches sagen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cricriat ()

  • @cricriat

    Hi,

    glaub mir oder glaub es nicht.
    Ich weiß aus Erfahrung, dass bei swappiness = 0 geswapped wird, wenn kein Memory mehr frei ist.
    Die Erfahrung haben andere offensichtlich auch schon gemacht.

    askubuntu.com/questions/969065…d-when-vm-swappiness-is-0

    Ist aber auch egal, es geht hier nicht um Prinzipien, sondern darum vernünftiges Memorymanagement zu haben.
    Ich will nicht, dass meine Box unnötig swapped und du sicherlich auch nicht.
    2 x Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
  • redzoro schrieb:

    askubuntu.com/questions/969065…d-when-vm-swappiness-is-0


    Ja, das sind natürlich sehr widersprüchliche Aussagen, die geradezu zu Mißverständnissen führen müssen.

    Daß die Box swapped, besonders nicht bei der Filmwiedergabe, will keiner, ist ja klar.
    Wenn man mal erlebt hat wie sich eine Maschine verhält, die keinen Speicher mehr
    bereit stellen kann (swap death), dann möchte man das aber auch nicht. :D

    Falls sich für die, die das Rucklerproblem haben, Verbesserungen ergeben (und so sieht es ja bis jetzt aus),
    dann sind Deine Werte ja sehr hilfreich.
  • Also mit diesen Einstellungen wird die HD51 unbedienbar und crasht laufend vor sich hin.
    FTP usw. gehen dann auch nicht mehr.
    Also Vorsicht beim testen. Ich konnte die Werte noch per Samba Freigabe zurück ändern und per Telnet rebooten.
    Meine Bastelboxen: Mut@nt HD51 | GB Quad 4K | Mut@nt HD60 | OSMIO4K | HIS 4k Combo+

    ... Keinen Support per PN ... bitte stellt eure Fragen ins Forum!...

    ~ Benutzung OpenHDF Image ~ Benutzung der HDF-Toolbox ~ FAQ und Linksammlung ~ Build und Foren Server Spendenaktion ~
  • Ist eine klare Erkenntnis, überrascht mich aber.

    Kannst du mal hier den Output von free posten. Am besten während einer Wiedergabe, wenn die ca. 10 Minuten gelaufen ist. Würde mich einfach mal interessieren.
    2 x Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
  • Klar doch:

    Quellcode

    1. root@mutant51:~# free
    2. total used free shared buff/cache available
    3. Mem: 1028048 823292 41440 292 163316 192348
    Meine Bastelboxen: Mut@nt HD51 | GB Quad 4K | Mut@nt HD60 | OSMIO4K | HIS 4k Combo+

    ... Keinen Support per PN ... bitte stellt eure Fragen ins Forum!...

    ~ Benutzung OpenHDF Image ~ Benutzung der HDF-Toolbox ~ FAQ und Linksammlung ~ Build und Foren Server Spendenaktion ~
  • Nein nicht bei diesem Stand. Kommt mit dem nächsten Build dann.
    Muss aber nur wegen der Basteleien für Kodi sein.
    Meine Bastelboxen: Mut@nt HD51 | GB Quad 4K | Mut@nt HD60 | OSMIO4K | HIS 4k Combo+

    ... Keinen Support per PN ... bitte stellt eure Fragen ins Forum!...

    ~ Benutzung OpenHDF Image ~ Benutzung der HDF-Toolbox ~ FAQ und Linksammlung ~ Build und Foren Server Spendenaktion ~
  • Ich hab seit wahrscheinlich mittlerweile 10 Jahren nicht verstanden, warum das "Swappen" als negativ dargestellt wird?

    Eine Linux-Distribution egal welcher Art wird nicht langsamer wenn sie swapped.
    Jeder vernünftig ausgelegte e2-Receiver sollte swap nutzen. Dies ist ein Mehrwert.
    Soweit ich das bisher gesehen habe, wurde dies auch bei allen ARM und Hisi Boxen aktiviert.
    Leider eben nicht gleichermaßen sorgfältig.
    Warum also

    Quellcode

    1. vm.swappiness = 0


    Dies ist eher ein Problem, als ein Segen, wenn erst geswapped wird, wenn es schon zu spät ist.
    Aus meiner bescheidenen Erfahrung mit Swap und deutlich schwächeren e2-Boxen würde ich dort auch immer eine Wert größer 50 eintragen.

    Grüße

Flag Counter