Existe-t-il une relation entre la fragmentation de la mémoire et l'activation ou non du swap sur un système?


8

L'une des réponses à Ai-je besoin d'espace de swap si j'ai plus qu'assez de RAM? m'a fait me demander s'il existe une relation entre la fragmentation de la mémoire mesurée par cat /proc/buddyinfo et si le swap est utilisé ou non. Pour être plus précis, je me demande si l'utilisation du swap peut réduire la fragmentation de la mémoire. Pendant un travail normal avec swap off sur mon système, j'ai ceci:

tvbox@tvbox-G31M-ES2L:~$ cat /proc/buddyinfo
Node 0, zone      DMA      3      3      4     14     16      6      2      0      0      1      0 
Node 0, zone   Normal   1564   1052    462    356    240    109     33     21      6      1      0 
Node 0, zone  HighMem     43   1972    839    285    183    109     98     34     16      0      0 
tvbox@tvbox-G31M-ES2L:~$ free
             total       used       free     shared    buffers     cached
Mem:       2053888    1821904     231984     171376     299908     812940
-/+ buffers/cache:     709056    1344832
Swap:            0          0          0

Remarque: ce système a un temps de disponibilité qui ne dépasse jamais 18 heures.

Sur un système plus utilisé, j'ai ceci:

me@me-zippy:~$ cat /proc/buddyinfo
Node 0, zone      DMA    149    106     70     26     15      5      4      0      0      2      0 
Node 0, zone   Normal   2455   3527   4651   1421    367    157     61     19     14      3      0 
Node 0, zone  HighMem      7     43     75    266    166    162     91     43     27      0      0 
me@me-zippy:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          7.4G       7.0G       351M       281M       116M       6.0G
-/+ buffers/cache:       967M       6.4G
Swap:           0B         0B         0B
me@me-zippy:~$ uptime
 12:01:49 up 3 days,  3:20,  2 users,  load average: 0.52, 0.23, 0.17

Vous remarquerez qu'aucun de ces systèmes n'a activé l'échange.


4
Par curiosité, pourquoi serait-il important que la mémoire soit fragmentée? Ce n'est pas comme un disque dur où la recherche de temps compte. La mémoire apparaîtra toujours logiquement contiguë dans l'espace d'adressage virtuel du processus, de sorte que l'espace utilisateur ne peut même pas dire si la mémoire est fragmentée au niveau physique. Est-ce parce que les tables de traduction de pages deviennent plus compliquées?
Celada

Bonne question. La condition a été soulevée comme raison d'utiliser le swap. Je reste sceptique, je recherche donc un lien entre l'utilisation du swap et la fragmentation de la mémoire. Je ne m'attends pas à en trouver un, mais je suis toujours prêt à changer de position face à de nouvelles informations. Je pourrais finir par répondre à celui-ci moi-même après de nouveaux tests.
Elder Geek

Réponses:


3

L'échange permet de déplacer des pages physiques, dans le sens où une page utilisée dans un but peut voir son contenu échangé puis utilisé dans un autre but.

Dans un système de gestion de mémoire virtuelle de type jardin, il n'y a pas de fragmentation de la mémoire physique en ce qui concerne les applications. Chaque page allouée par une application peut être prise n'importe où dans la mémoire physique, il n'y a aucune raison pour que deux pages consécutives dans la mémoire virtuelle aient besoin d'avoir une proximité particulière dans la mémoire physique.

Il existe de nombreux cas où la fragmentation de la mémoire est un problème: toutes les circonstances dans lesquelles l'emplacement de la mémoire physique est important. Ceci comprend:

  • Paravirtualisation , où les machines virtuelles décident à qui appartient la page physique avec une granularité plus grossière qu'une page.
  • De même, les clusters où plusieurs nœuds partagent le même pool de RAM.
  • Mémoire utilisée par les périphériques, qui nécessite généralement de grands tampons contigus.
  • Optimisations telles que des pages énormes .

En l'absence de scénarios «complexes», la fragmentation de la mémoire physique pourrait entraîner des problèmes de connexion d'un nouveau périphérique qui nécessite un pool de mémoire contiguë (le noyau conserve ces pools pour cela, mais ils pourraient avoir besoin d'être agrandis si un pilote crée soudainement un grand demande). Si l'utilisation du périphérique est constante, la fragmentation physique n'aurait pas d'importance et, en particulier, n'entraînerait pas le ralentissement ou le manque d'espace d'une application.

Il est possible que la fragmentation de l'espace d'adressage physique conduise à l'utilisation de plus de mémoire dans le noyau pour représenter la liste libre. Je ne pense pas que ce soit le cas sous Linux mais je suis loin d'être un expert de la gestion de sa mémoire.

Pour résumer, autoriser l'échange d'une partie d'une application ne permet pas à cette application d'allouer plus de mémoire, mais pourrait permettre à certains pilotes matériels d'allouer la mémoire dont ils ont besoin.

L'ajout de swap n'a aucun effet sur l'espace mémoire virtuel de l'application. C'est le point de l'échange, après tout - c'est transparent pour les applications.

Cependant, il est possible que l'ajout de swap à une machine ait une influence indirecte sur la fragmentation à l'intérieur de l'espace mémoire virtuel d'une application. Si le système manque de mémoire virtuelle, l'application devra faire avec ce qu'elle a. Si l'application utilise la majeure partie de la mémoire qu'elle a allouée à partir du système d'exploitation, cela entraînera au fil du temps une fragmentation à l'intérieur de cet espace car de petits blocs sont libérés ici et là. Si l'application dispose de plus de mémoire virtuelle (dont une partie est remplacée), cela donne au gestionnaire de mémoire plus de marge de manœuvre et réduit ainsi le risque que l'application manque de mémoire, avec trois blocs distincts de 2 Ko disponibles quand il en souhaite un seul. Objet de 4 Ko.


N'est-il pas intéressant de voir comment chaque réponse mène à une nouvelle question? Maintenant, je suis curieux de connaître l'ordre des opérations de gestion de la mémoire et quelles techniques pour libérer de la mémoire doivent échouer avant qu'une condition de mémoire insuffisante soit atteinte. Mon hypothèse est que le cache est le moins important et serait vidé en premier. Je sais qu'il y a un noyau de vérité quelque part ici (jeu de mots voulu). ;-)
Elder Geek

@ElderGeek - Documentation / cgroups / memory.txt est probablement un bon point de départ. Bien qu'il soit désespérément obsolète, il présente assez bien le contrôleur de mémoire du noyau.
mikeserv

@mikeserv Merci pour cela. J'ai également trouvé - landley.net/writing/memory-faq.txt qui semble également être "désespérément obsolète" mais au moins il semble que ma théorie concernant le dumping logique du cache pour libérer de la mémoire RAM avant de recourir à la mise à mort les processus sont précis. Je doute que j'en apprenne beaucoup plus à ce sujet sans me plonger dans le code lui-même. Cela pourrait être un peu au-delà de moi car je n'ai pas écrit de code au-delà du script bash depuis des décennies ...
Elder Geek
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.