Cache freigegeben. Ist diese Option gefahrlos nutzbar?

Dec 19, 2012
476
14
83
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ß!
 
Last edited:
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.
free && sync && echo 3 > /proc/sys/vm/drop_caches && free
Der Befehl macht nichts anderen wie den Cache zu leeren, damit solltest du keinerlei Probleme bekommen.


Grüße,
Kevin
 
Last edited:
ZFS benutz standardmäßig den gesamten verfügbaren Ram als Cache.

Die Hälfte des verbauten Caches, sonst korrekt erklärt.

damit solltest du keinerlei Probleme bekommen.

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.
 
  • Like
Reactions: stenzelprox
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?
 
War die VM denn aus?
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??
 
Ja, das ist das seltsame daran.

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?
 
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.
 
Ich würde auch ein Monitoring laufen lassen; habe bisher keins für arcstat -- welches empfiehlst du?

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.

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.

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?
 
Ist dein Host denn überfrachtet mit VMs oder warum benötigen die 256-64 GB RAM?
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.

Nur damit wir alle Fragen mal gestellt haben: umstellen von Snapshot-Backup auf Shutdown-Backup ist keine Lösung für dich?
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?
 
Die Summe aller Hardware-Ressourcen (RAM) beträgt dabei auch "nur! 188 GB, liegt also immernoch deutlich unter 256 GB.

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.

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

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?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!