Cache freigegeben. Ist diese Option gefahrlos nutzbar?

Discussion in 'Proxmox VE (Deutsch)' started by whiterabbit, Aug 13, 2019.

  1. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Hallo.
    Ich habe in einem anderen Thread bereits über diverse Schwierigkeiten beim nächtlichen Backup diverser VMs geschrieben. Mir kam es so vor, als wenn der Speicher voll gelaufen ist, obwohl die Kiste 256 GB RAM hat, von denen eigentlich nur ~80GB belegt gewesen sein dürften.

    Nun bin ich bei der Suche nach einer Lösung über diesen Beitrag gestolpert:
    https://www.reddit.com/r/Proxmox/comments/8sy4sd/unable_to_start_vm/

    Das habe ich einfach mal ausprobiert ... und siehe da:
    Vorher:
    Code:
    free
                  total        used        free      shared  buff/cache   available
    Mem:      264114444    82797328     1041048       97532   180276068   179361584
    Swap:      20971516      494636    20476880
    
    und nach den Befehlen:
    Code:
      free && sync && echo 3 > /proc/sys/vm/drop_caches && free
    Code:
    free
                  total        used        free      shared  buff/cache   available
    Mem:      264114444    81492068   181135068       97528     1487308   180872436
    Swap:      20971516      494636    20476880
    
    Nun ist also viel mehr Speicher "free" als zuvor.
    Die Frage ist nur: Ist das gefahrlos so machbar? Man kann sich ja grob vorstellen, was der Befehl bewirkt -- aber was sagen die Wizzzards dazu? Empfehlenswert oder lieber die Finger davon lassen?

    Schönen Gruß!
     
    #1 whiterabbit, Aug 13, 2019
    Last edited: Aug 13, 2019
  2. stenzelprox

    stenzelprox New Member

    Joined:
    Jan 11, 2018
    Messages:
    28
    Likes Received:
    3
    Hallo,
    Ich gehe mal davon aus, dass du als Dateisystem ZFS verwendest richtig ?

    ZFS benutz standardmäßig den gesamten verfügbaren Ram als Cache. Diesen kannst du aber beschränken.

    Dafür musst du die Datei /etc/modprobe.d/zfs.conf anlegen, darin kannst du dann mit den Parametern options zfs zfs_arc_min und options zfs zfs_arc_max die Cache grenze festlegen.
    Code:
    root@vhost:~# cat /etc/modprobe.d/zfs.conf
    ## den von zfs arc max zu verwendende RAM-Speicher:
    ## in Byte, hier =
    ##  2GB=2147483648
    ##  4GB=4294967296
    ##  8GB=8589934592
    ## 12GB=12884901888
    ## 16GB=17179869184
    ## 24GB=25769803776
    ## 32GB=34359738368
    
    options zfs zfs_arc_min=2147483648
    options zfs zfs_arc_max=12884901888
    
    Wenn die Datei angelegt ist musst du noch einmal folgenden Befehl absetzen.
    Code:
    update-initramfs -u
    
    Zum Schluss noch neustarten.

    Nach mal kurz zu dem Befehl.
    Der Befehl macht nichts anderen wie den Cache zu leeren, damit solltest du keinerlei Probleme bekommen.


    Grüße,
    Kevin
     
    #2 stenzelprox, Aug 14, 2019
    Last edited: Aug 14, 2019
  3. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    Die Hälfte des verbauten Caches, sonst korrekt erklärt.

    Keinerlei Konsistenzprobleme. Dein System wird danach erstmal extrem langsam sein, denn alle gecachten Inhalte, die für die laufenden Prozesse relevant sind müssen dann natürlich wieder von der Disk geladen werden, was je nach Menge der notwendigen Daten erheblich spürbar ist.
     
    stenzelprox likes this.
  4. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Hallo.
    Ok, ich habe den arc-cache seinerzeit so gesetzt -- ist das evtl zu klein?
    Code:
    # Don't let ZFS use less than 4GB and more than 64GB
    options zfs zfs_arc_min=4294967296
    options zfs zfs_arc_max=68719476736
    #
    # disabling prefetch is no longer required
    options zfs l2arc_noprefetch=0
    Meines Wissens ist er bisher nicht größer als 6.x GB gewesen; im Moment bei 4GB.

    Wenn ich jetzt wieder free aufrufe, sieht die Welt auch schon wieder ganz anders aus:
    Code:
    free -g
                  total        used        free      shared  buff/cache   available
    Mem:            251          77          13           0         160         172
    Swap:            19           0          19
    
    Kann das Backup-Problem aus dem anderen Thread denn damit zusammenhängen, dass die VM aufgrund von "mangelndem Speicher" (?) nicht gestartet werden kann?
     
  5. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    War die VM denn aus?
     
  6. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Ja, das ist das seltsame daran. Es trifft immer andere VMs ... letzte Nacht waren es gleich 4. Die Meldungen hatte ich in dem anderen Thread ja bereits gepostet. Es tritt nach wie vor auf -- es muss mit ZFS zusammenhängen, da die VMs vorher auf einem "normalen RAID-10" liefen und dieses Verhalten nicht zeigten. Und es sind immer VMs, die nicht laufen ...
    Seltsam, dass sonst scheinbar niemand betroffen ist??
     
  7. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    Find ich nicht seltsam :p

    Es ist das "Problem" mit dem zu geringen Arbeitsspeicher, da die VM beim Backup gestartet sein muss, wenn du snapshot-Mode verwendest (Standard). Ist auch einleuchtend, dass es vorher im RAID 10 nicht da war, denn dort gibt es keinen ARC und der "normale" Cache des Kernels wird geopfert, wenn du nicht genug Speicher hast. Es ist aber komisch, dass der ARC nicht geopfert wird wenn es eng wird.

    Am Besten also den Speicher ca. so planen:
    - 1 GB für "normales Linux Zeugs" in PVE
    - x GB für ARC fest einplanen
    - Rest für VMs

    Wobei 64 GB für ARC (1/4 RAM) schon ne gute Größe ist. Klappt es damit denn jetzt besser? Hast du ein Monitoring laufen, bei dem du den ARC und den "normalen" RAM dir anschauen kannst?
     
  8. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Also der Arbeitsspeicher kann mit 256 GB wohl kaum als zu gering angesehen werden. Ich hatte den ARC-Cache schon relativ schnell nach der Einrichtung in der Größe auf 64 GB begrenzt -- das Problem tritt trotzdem fast jede Nacht auf. Ich kann die Größe aber auch nochmal höher drehen; dann wäre allerdings ein Neustart fällig, nehme ich mal stark an?

    Ich würde auch ein Monitoring laufen lassen; habe bisher keins für arcstat -- welches empfiehlst du?

    Ich nehme jedenfalls auch an, dass es daran liegt, dass die VMs für das Backup "sowas ähnliches wie gestartet werden müssen" und daher alle (gleichzeitig?) RAM anfordern.
     
  9. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    telegraf kann das alles. Generell ist aber aber eigentlich nur ein paar Werte aus /proc/spl/kstat/zfs/arcstats auslesen, das kann dein jetziges vielleicht auch.

    Sie sollten nacheinander Speicher anfordern, da die Backups auf einem Host nicht parallel gestartet werden. Ist dein Host denn überfrachtet mit VMs oder warum benötigen die 256-64 GB RAM?

    Nur damit wir alle Fragen mal gestellt haben: umstellen von Snapshot-Backup auf Shutdown-Backup ist keine Lösung für dich?
     
  10. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Ich kann nicht so genau sagen, ob der Server überfrachtet ist. Es sind dort 27 VMs installiert, von denen aber "nur" 11 ständig laufen. Bisher hat das nie Probleme gemacht. Die Summe aller Hardware-Ressourcen (RAM) beträgt dabei auch "nur! 188 GB, liegt also immernoch deutlich unter 256 GB. Die größten Maschinen habe ich bereits zurückgestutzt und haben jetzt "nur noch" 16GB RAM.

    Ich meine ,dass ich das irgendwann mal ausprobiert hatte ...und dann festgestellt hatte, dass es ewig gedauert hat?! Ich habe hier leider eine VM dabei, die ein 300GB Abbild erzeugt, da dort viele User-Daten liegen. Das bläht das ganze mächtig auf.
    Allerdings habe ich für einige VMs bereits zfs-auto-snapshot eingerichtet. Aber auch das ist speicherhungrig, wenn man's z.B. nur auf 7 Snapshots begrenzt. Damit passen hier leider nicht alle VMs auf den ZFS-Pool (obwohl ich das eigentlich gerne so hätte).

    Telegraf kannte ich bisher nicht. Eigentlich haben wir check_mk installiert, doch ich bin nicht sicher, ob das auch den ZFS-Pool überwachen kann?
     
  11. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    Es liegt nur 3 GB unter Limit von 256 - 64 - 1, aber es liegt darunter. Aber wenn die Maschinen nicht alle an sind, sollte das ja generell klappen.

    k.a. was check_mk alles kann oder nicht, aber ich denke es kommt doch bestimmt mit Nagios-kompatiblen Plugins zurecht und da gibt es einige die den ARC überwachen. Da du mit check_mk bestimmt ja auch den RAM überwachst, wie sieht es da um den Backup-Zeitpunkt aus, sieht man dass der RAM zu wenig ist? Wieviel ist frei?
     
  12. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
  13. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,937
    Likes Received:
    365
    Jo, @morph027 ist hier auch unterwegs.

    Hier müssten wir genau wissen wieviel frei+cached ist um eine Aussage treffen zu können. Hast du Graphen dazu?
     
  14. whiterabbit

    whiterabbit Member
    Proxmox Subscriber

    Joined:
    Dec 19, 2012
    Messages:
    232
    Likes Received:
    4
    Hab' noch nicht rausgefunden, wie/wo ich das unter check_MK aktiviere ... ist hier aber OT
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice