Pourquoi le paramètre arc_max n'est-il pas respecté sur ZFS sous Linux?

J'utilise ZoL 0.6.2 à partir de leur PPA sur Ubuntu 12.04. C'est sur un hôte avec 16 Go de mémoire destiné à exécuter certaines machines virtuelles en utilisant KVM / Libvirt. Après un certain temps, ZoL utilise une quantité insensée de mémoire, atteignant 98% de l'utilisation de la RAM avec certaines machines virtuelles en cours d'exécution. Il en résulte de nouveaux processus refusant de démarrer "impossible d'allouer de la mémoire". Je ne peux 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_maxparamètre 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 sur les statistiques ARC ci-dessous, il utilise plus de mémoire que ce qu'il est configuré pour (comparer c= 7572030912avec 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, on peut changer 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 avec >>.

source: /programming//a/18808311

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 la libération de la RAM, il est nécessaire d'exporter le zpool.

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 les E / S attendre un instant avant que le cache ne soit repeuplé.

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.

AFAIK une des conditions suivantes doit être remplie pour adapter le paramètre.

1. 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).
2. 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.

Vous en avez un " >" trop.

La commande doit être

echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_max

pas " >>"

>>signifie "ajouter à" (liste existante).
>signifie "écraser" (valeur).

C'est pourquoi le code de commande de votre question ne fonctionnera pas.