Aller au contenu

RAM et ARC : combien, limiter l'ARC sur un hôte PVE

Day 0 · ConcevoirNiveau 2 · OpérerCoursRédigé · à valider en lab

Sur un hôte Proxmox VE, l'ARC (le cache de lecture de ZFS en RAM) doit être plafonné pour laisser la mémoire aux VM : comptez 2 Gio plus 1 Gio par Tio de stockage, puis fixez cette valeur dans /etc/modprobe.d/zfs.conf. Depuis PVE 8.1, l'installeur le fait déjà : 10 % de la RAM, plafonné à 16 Gio.

Notions clés

Terme Définition
ARC Adaptive Replacement Cache : cache de ZFS en RAM, données et métadonnées récemment ou fréquemment lues
zfs_arc_max Taille maximale de l'ARC, en octets (paramètre du module noyau zfs)
zfs_arc_min Taille minimale ; par défaut 1/32 de la RAM, plancher 64 Mio
L2ARC Extension de l'ARC sur SSD ; consomme elle-même de la RAM (voir Special vdev, SLOG, L2ARC)
Hit ratio Part des lectures servies par l'ARC ; un taux élevé n'impose pas un gros ARC

Valeurs par défaut : d'où vient votre limite ?

Cas Limite appliquée
Installé depuis l'ISO PVE 8.1 ou plus récent 10 % de la RAM, plafonné à 16 Gio, écrit dans /etc/modprobe.d/zfs.conf
Installé avant PVE 8.1 puis mis à jour Aucune limite écrite : défaut ZFS
Défaut ZFS (pas de ligne zfs_arc_max) 62,5 % de la RAM avec OpenZFS 2.3 (50 % avant 2.3)

Une mise à niveau majeure ne réécrit pas ce fichier. Un nœud installé en PVE 7 et migré en PVE 9 peut donc laisser ZFS prendre 62,5 % de sa RAM.

Combien de RAM pour l'ARC ?

La documentation Proxmox donne une règle simple : 2 Gio de base + 1 Gio par Tio de stockage. Exemple : pool de 8 Tio utiles → 10 Gio d'ARC.

RAM du nœud Pool Défaut installeur (10 %, max 16 Gio) Règle 2 + 1/Tio Choix conseillé
64 Gio 2 Tio SSD 6,4 Gio 4 Gio 4 à 6 Gio
128 Gio 8 Tio SSD 12,8 Gio 10 Gio 10 à 12 Gio
256 Gio 15 Tio SSD 16 Gio 17 Gio 16 Gio
64 Gio (PBS) 60 Tio HDD 6,4 Gio 62 Gio Le plus possible, et special vdev

Bilan mémoire d'un nœud :

RAM nécessaire = RAM des VM (somme des « Memory » configurés)
               + ARC maximum
               + 4 à 8 Gio pour l'hôte (pveproxy, corosync, pvestatd, ksm…)
               + marge pour un nœud qui reprend les VM d'un autre (HA, réplication)

Sur une architecture ZFS répliqué 2 nœuds, chaque nœud doit pouvoir porter les VM des deux : dimensionnez la RAM pour ce cas.

Changer la limite

Exemple : limiter l'ARC à 8 Gio (8 × 1024³ = 8589934592 octets) sur pve01.

# 1. Effet immédiat, perdu au redémarrage
echo "$[8 * 1024*1024*1024]" > /sys/module/zfs/parameters/zfs_arc_max

# 2. Persistant : une seule ligne options dans le fichier
cat /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf

# 3. Indispensable si le système démarre sur ZFS (rpool) : le module est chargé depuis l'initramfs
update-initramfs -u -k all

# 4. Redémarrer lors d'une maintenance (RB-02) pour valider la valeur au boot

Si la nouvelle valeur zfs_arc_max est inférieure ou égale à zfs_arc_min, elle est ignorée : ajoutez alors une ligne zfs_arc_min plus basse (par exemple options zfs zfs_arc_min=4294967296 zfs_arc_max=8589934592).

Vérification :

grep -E '^(c_max|size) ' /proc/spl/kstat/zfs/arcstats   # c_max = limite, size = taille actuelle (octets)
arc_summary | head -40                                  # résumé lisible, taux de hit
arcstat 5                                               # activité toutes les 5 s

Recommandations MSP

  • Contrôlez /etc/modprobe.d/zfs.conf sur chaque nœud lors de la recette et après chaque mise à niveau majeure.
  • Ne réduisez pas l'ARC sous 4 Gio sur un pool de VM : les métadonnées ne tiennent plus en cache et chaque lecture coûte plusieurs I/O disque.
  • Sur un PBS avec datastore ZFS sur HDD, privilégiez un gros ARC et un special vdev : le garbage collection et le verify lisent énormément de métadonnées.
  • Avant d'acheter un L2ARC, ajoutez de la RAM : c'est presque toujours plus efficace.
  • La mémoire affichée « utilisée » par le nœud inclut l'ARC. Un nœud à 90 % de RAM avec 16 Gio d'ARC n'est pas forcément en manque : l'ARC rend la mémoire sous pression, mais pas instantanément.

Pièges vus en support

  • Nœud migré depuis PVE 7 sans ligne zfs_arc_max : l'ARC prend jusqu'à 62,5 % de la RAM, le noyau tue des VM (OOM killer) au démarrage d'une grosse VM.
  • zfs.conf modifié sans update-initramfs -u -k all sur un hôte démarrant sur rpool : l'ancienne valeur revient au redémarrage.
  • Valeur écrite en Go (zfs_arc_max=8G) au lieu d'octets : le paramètre attend un nombre d'octets.
  • Deux lignes options zfs contradictoires dans deux fichiers de /etc/modprobe.d/ : la valeur réellement appliquée est difficile à prévoir. Une seule ligne, dans zfs.conf.
  • Ballooning et KSM comptés comme RAM disponible : ils réduisent la consommation, ils ne la garantissent pas.

Testez-vous

  1. Un nœud de 192 Gio a été installé avec l'ISO PVE 9. Quelle est sa limite d'ARC par défaut ?

    Réponse

    10 % de 192 Gio = 19,2 Gio, plafonné à 16 Gio. La limite est donc 16 Gio, écrite dans /etc/modprobe.d/zfs.conf.

  2. Quelle taille d'ARC la règle Proxmox conseille-t-elle pour un pool de 12 Tio ?

    Réponse

    2 Gio + 12 × 1 Gio = 14 Gio.

  3. Vous avez modifié zfs.conf et redémarré, mais c_max n'a pas changé. Que manque-t-il probablement ?

    Réponse

    La régénération de l'initramfs (update-initramfs -u -k all) : sur un hôte démarrant sur ZFS, le module est chargé avec les options contenues dans l'initramfs. Autre cause possible : une valeur inférieure ou égale à zfs_arc_min.

  4. Où lire la taille actuelle de l'ARC et sa limite ?

    Réponse

    Dans /proc/spl/kstat/zfs/arcstats (lignes size et c_max), ou avec arc_summary.

Pour aller plus loin