Pourquoi le paramètre arc_max n'est-il pas respecté sur ZFS sous Linux?
J'utilise ZoL 0.6.2 depuis leur PPA sur Ubuntu 12.04. C'est sur un hôte avec 16 Go de mémoire destiné à exécuter certaines machines virtuelles à l'aide de KVM/Libvirt. Après un certain temps, ZoL utilise une quantité insensée de mémoire, atteignant 98% de RAM utilisation avec certaines machines virtuelles en cours d'exécution. Cela entraîne de nouveaux processus refusant de démarrer "impossible d'allouer de la mémoire". Je ne peux pas même plus démarrer toutes mes machines virtuelles qui, avant d'utiliser ZFS, utilisaient environ 40 à 50% de RAM.
Si je comprends bien, sans peaufiner, ZoL devrait libérer de la mémoire dès que le système est à court de mémoire. Et bien non. J'ai donc décidé de définir le arc_max réglage sur 1 Go.
# echo 1073741824 >> /sys/module/zfs/parameters/zfs_arc_max
Pourtant, il ne libère aucune mémoire.
Comme vous pouvez le voir dans les statistiques ARC ci-dessous, il utilise plus de mémoire que ce qu'il est configuré pour (comparer c = 7572030912 avec c_max = 1073741824).
Qu'est-ce que je fais mal ici?
# cat /proc/spl/kstat/zfs/arcstats
4 1 0x01 84 4032 43757119584 392054268420115
name type data
hits 4 28057644
misses 4 13975282
demand_data_hits 4 19632274
demand_data_misses 4 571809
demand_metadata_hits 4 6333604
demand_metadata_misses 4 289110
prefetch_data_hits 4 1903379
prefetch_data_misses 4 12884520
prefetch_metadata_hits 4 188387
prefetch_metadata_misses 4 229843
mru_hits 4 15390332
mru_ghost_hits 4 1088944
mfu_hits 4 10586761
mfu_ghost_hits 4 169152
deleted 4 35432344
recycle_miss 4 701686
mutex_miss 4 35304
evict_skip 4 60416647
evict_l2_cached 4 0
evict_l2_eligible 4 3022396862976
evict_l2_ineligible 4 1602907651584
hash_elements 4 212777
hash_elements_max 4 256438
hash_collisions 4 17163377
hash_chains 4 51485
hash_chain_max 4 10
p 4 1527347963
c 4 7572030912
c_min 4 1038188800
c_max 4 1073741824
size 4 7572198224
hdr_size 4 66873056
data_size 4 7496095744
other_size 4 9229424
anon_size 4 169150464
anon_evict_data 4 0
anon_evict_metadata 4 0
mru_size 4 1358216192
mru_evict_data 4 1352400896
mru_evict_metadata 4 508928
mru_ghost_size 4 6305992192
mru_ghost_evict_data 4 4919159808
mru_ghost_evict_metadata 4 1386832384
mfu_size 4 5968729088
mfu_evict_data 4 5627991552
mfu_evict_metadata 4 336846336
mfu_ghost_size 4 1330455552
mfu_ghost_evict_data 4 1287782400
mfu_ghost_evict_metadata 4 42673152
l2_hits 4 0
l2_misses 4 0
l2_feeds 4 0
l2_rw_clash 4 0
l2_read_bytes 4 0
l2_write_bytes 4 0
l2_writes_sent 4 0
l2_writes_done 4 0
l2_writes_error 4 0
l2_writes_hdr_miss 4 0
l2_evict_lock_retry 4 0
l2_evict_reading 4 0
l2_free_on_write 4 0
l2_abort_lowmem 4 0
l2_cksum_bad 4 0
l2_io_error 4 0
l2_size 4 0
l2_asize 4 0
l2_hdr_size 4 0
l2_compress_successes 4 0
l2_compress_zeros 4 0
l2_compress_failures 4 0
memory_throttle_count 4 0
duplicate_buffers 4 0
duplicate_buffers_size 4 0
duplicate_reads 4 0
memory_direct_count 4 66583
memory_indirect_count 4 7657293
arc_no_grow 4 0
arc_tempreserve 4 0
arc_loaned_bytes 4 0
arc_Prune 4 0
arc_meta_used 4 427048272
arc_meta_limit 4 2076377600
arc_meta_max 4 498721632
# free -m
total used free shared buffers cached
Mem: 15841 15385 456 0 75 74
-/+ buffers/cache: 15235 606
Swap: 0 0 0
À mon humble avis, les paramètres dans/sys/module/zfs/parameters ne peuvent être définis que sur 0/1 - disabled/enabled. " Correction: dépend du paramètre
Je suis dans le même bateau, je veux limiter l'utilisation de la mémoire de zfs et il semble que l'on doive créer un fichier /etc/modprobe.d/zfs.conf et y entrer le paramètre et la valeur souhaitée. Cette modification prendra effet au redémarrage.
echo "options zfs zfs_arc_max=34359738368" >> /etc/modprobe.d/zfs.conf
Pour effectuer le module en cours d'exécution, vous pouvez modifier le paramètre zfs_arc_max.
echo "34359738368" > /sys/module/zfs/parameters/zfs_arc_max
Veuillez noter l'utilisation de > pour remplacer le contenu du fichier contrairement à l'ajout au fichier par >>.
Une fois que vous avez modifié la taille de votre arc, vous devez supprimer vos caches.
echo 3 > /proc/sys/vm/drop_caches
et attendez (votre invite ne reviendra pas immédiatement, mais d'autres processus continueront de s'exécuter). Il déchargera lentement les caches (2,5 min pour mon cache de 24 Go sur 2 paires de noirs WD raid 1 To 2 To sur un processeur 2Ghz 4 ans sur une boîte avec 64 Go) - attention, vous n'aurez soudainement plus de caches, et tout les processus de lecture des données retireront le disque brut, vous verrez donc probablement IO attendre sauter pendant un certain temps jusqu'à ce que le cache soit repeuplé.
http://fibrevillage.com/storage/169-zfs-arc-on-linux-how-to-set-and-monitor-on-linux
cet article est très bon
à partir de la version ZoL 0.6.2, vous pouvez définir le c_max au moment de l'exécution, mais la taille ARC ne sera pas publiée automatiquement. pour forcer le RAM à être libéré, il est nécessaire d'exporter le zpool.
Un problème dans lequel vous pourriez tomber est la mise en cache ZFS des fichiers de la machine virtuelle (disques virtuels). Pour éviter cela, je définis toujours la propriété primarycache sur "metadata" sur les systèmes de fichiers contenant des disques virtuels.
La logique étant que le système d'exploitation invité a une meilleure idée des zones de ses disques à mettre en cache.
Vous avez un extra ">" trop.
La commande doit être
echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_max
ne pas ">> "
>> signifie "ajouter à" (liste existante).> signifie "écraser" (valeur).
C'est pourquoi le code de commande de votre question ne fonctionnera pas.
AFAIK une des conditions suivantes doit être remplie pour adapter le paramètre.
- Sur un système en cours d'exécution: exportez tous les zpools, supprimez les modules zfs, réactivez le module zfs (par définition, cela ne peut pas être fait si/est sur zfs).
- Régénérez l'image initramfs lors de la modification du paramètre, donc après un redémarrage, cela fonctionnera. Ceci est nécessaire car l'emplacement du fichier zfs.conf n'est pas encore monté à ce moment dans le processus de démarrage.