Pourquoi l’ARC de ZFS diminue-t-il lorsque l’IA locale utilise de la mémoire hôte épinglée ?

L’ARC de ZFS diminue lors de l’utilisation de mémoire hôte épinglée, car les tampons de transfert d’IA non récupérables accentuent la pression sur la mémoire que le noyau peut récupérer, notamment le cache du système de fichiers.

Les environnements d’exécution GPU épinglent les pages hôtes afin que les périphériques puissent transférer des données sans que ces pages soient déplacées ou envoyées dans le swap en cours d’opération. Cela améliore la prévisibilité des transferts DMA, mais les allocations épinglées sont difficiles à récupérer lorsque la RAM disponible diminue. Linux lance alors la récupération de mémoire et les mécanismes de réduction, tandis que ZFS réagit en expulsant les blocs mis en cache ou en abaissant la cible de son ARC, libérant ainsi davantage de mémoire pour les allocations qui ne peuvent pas céder de place.

Les pages épinglées modifient la mémoire que le noyau peut récupérer

Les pages anonymes ordinaires peuvent être déplacées dans le swap, et les pages propres du cache de fichiers peuvent être supprimées. Les pages épinglées à long terme restent en mémoire, car un périphérique ou un pilote dépend de leur mappage physique, ce qui réduit le pool flexible disponible pour satisfaire de nouvelles allocations.

La documentation Linux consacrée à l’épinglage à long terme des pages distingue l’épinglage à long terme des pages des références ordinaires et explique pourquoi les utilisateurs de DMA doivent marquer les pages de manière appropriée. Ce mécanisme rend la mémoire épinglée qualitativement différente d’une allocation de processus que le noyau peut facilement déplacer ou récupérer.

Les frameworks d’IA utilisent des tampons de staging épinglés pour accélérer les copies de l’hôte vers le périphérique, les files d’attente des chargeurs de données et le déchargement. Plusieurs processus de travail ou des files de prélecture surdimensionnées peuvent maintenir épinglée une quantité de mémoire hôte bien supérieure à ce que suggère un seul lot visible. Cette distinction reste visible lors des tests domestiques ultérieurs.

L’ARC est par conception un grand consommateur récupérable

Le cache de remplacement adaptatif conserve les blocs ZFS récemment et fréquemment utilisés afin d’éviter les lectures sur le stockage. Sous Linux, il participe à la gestion de la pression mémoire et peut réduire sa taille résidente lorsque le système a besoin de pages ailleurs. Le résultat intermédiaire doit rester inspectable avant que l’automatisation poursuive.

La documentation OpenZFS sur la taille et la récupération de l’ARC décrit les contrôles de taille de l’ARC ainsi que les paramètres ajustables liés à la récupération. Une limite maximale configurée est un plafond, et non la garantie que les données mises en cache resteront résidentes sous pression. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

Lorsque les tampons épinglés augmentent, l’expulsion de données de l’ARC peut être la réponse appropriée plutôt qu’une fuite. La conséquence apparaît ensuite sous la forme d’un taux de succès du cache plus faible, de davantage de lectures sur disque et d’un accès aux fichiers plus lent après la fin du travail d’IA, jusqu’à ce que le cache se réchauffe à nouveau.

La mémoire unifiée et les métriques des conteneurs peuvent masquer la concurrence

Sur un GPU intégré, les tenseurs du modèle et le cache du système de fichiers utilisent la même RAM physique, même lorsque les tableaux de bord étiquettent différemment leur utilisation. Sur un GPU dédié, le staging hôte reste séparé de la VRAM, mais il est toujours en concurrence avec l’ARC sur le serveur.

L’implémentation du mécanisme de réduction de l’ARC d’OpenZFS pour Linux enregistre le comportement de récupération de l’ARC auprès de la gestion mémoire du noyau. Les éléments issus du code source aident à distinguer une réduction délibérée du cache d’une commande directe de l’application demandant à ZFS de supprimer des blocs. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La limite d’interprétation consiste à supposer que la mémoire est épinglée dès que l’ARC diminue. Une analyse volumineuse de fichiers, des limites explicites de l’ARC, une pression sur les métadonnées, la récupération par un cgroup, la croissance d’une machine virtuelle ou un comportement adaptatif normal peuvent produire le même graphique. Confirmez le nombre de pages épinglées et le moment des allocations.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Corrélez les octets épinglés avec la récupération de l’ARC et les défauts de cache

Exécutez une charge de travail d’IA fixe tout en enregistrant la mémoire épinglée ou non récupérable, MemAvailable, les blocages liés à la récupération, la taille et la cible de l’ARC, le taux de succès de l’ARC, les lectures ZFS, la taille du pool de tampons épinglés, le nombre de processus de travail, la taille des lots, la VRAM et la latence des requêtes. Incluez une référence de stockage sans IA.

Utilisez la mémoire hôte partagée pour distinguer les symptômes liés au processeur, à la mémoire et au stockage. Répétez le test avec des transferts paginables, une profondeur de prélecture plus faible, moins de processus de travail et un pool épinglé limité, en ne modifiant qu’un seul paramètre de contrôle par exécution. Cette dépendance doit rester explicite dans l’interface finale.

Considérez l’épinglage comme causal lorsque la contraction de l’ARC suit l’augmentation de la mémoire épinglée et s’atténue avec un pool plus petit. Limitez la taille du pool si les défauts de cache du stockage nuisent aux autres services, mais conservez suffisamment de pages épinglées pour éviter de priver l’accélérateur de ressources ; le bon équilibre dépend de la demande NAS simultanée.