Cache freigegeben. Ist diese Option gefahrlos nutzbar?

whiterabbit · Aug 13, 2019

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ß!

stenzelprox · Aug 14, 2019

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.

whiterabbit said:
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

LnxBil · Aug 14, 2019

stenzelprox said:
ZFS benutz standardmäßig den gesamten verfügbaren Ram als Cache.

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

stenzelprox said:
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.

whiterabbit · Aug 14, 2019

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?

LnxBil · Aug 15, 2019

whiterabbit said:
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?

whiterabbit · Aug 15, 2019

LnxBil said:
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??

LnxBil · Aug 16, 2019

whiterabbit said:
Ja, das ist das seltsame daran.

Find ich nicht seltsam

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?

whiterabbit · Aug 17, 2019

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.

LnxBil · Aug 17, 2019

whiterabbit said:
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.

whiterabbit said:
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?

whiterabbit · Aug 17, 2019

LnxBil said:
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.

LnxBil said:
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?

LnxBil · Aug 17, 2019

whiterabbit said:
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.

whiterabbit said:
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?

whiterabbit · Aug 17, 2019

Ich habe vorhin das hier entdeckt ... ist einen Versuch wert:
https://morph027.gitlab.io/post/proxmox-zfs-and-check-mk-zfs-arc-cache/

Damit werde ich zunächst mal den ARC-Cache überwachen - dann sehen wir weiter
Was den normalen RAM angeht: Ich könnte hier und da noch weiter reduzieren, so dass mehr als 3 GB übrig bleiben...!?

LnxBil · Aug 17, 2019

Jo, @morph027 ist hier auch unterwegs.

whiterabbit said:
Was den normalen RAM angeht: Ich könnte hier und da noch weiter reduzieren, so dass mehr als 3 GB übrig bleiben...!?

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

whiterabbit · Aug 17, 2019

Hab' noch nicht rausgefunden, wie/wo ich das unter check_MK aktiviere ... ist hier aber OT

Search

Search

Cache freigegeben. Ist diese Option gefahrlos nutzbar?

whiterabbit

Renowned Member

stenzelprox

Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member

LnxBil

Distinguished Member

whiterabbit

Renowned Member