Comprendre l'utilisation de la mémoire virtuelle> swap + physical sous Linux

J'ai un processus qui signale en «haut» qu'il a 6 Go de mémoire résidente et 70 Go de mémoire virtuelle alloués. Ce qui est étrange, c'est que ce serveur particulier ne dispose que de 8 Go physiques et de 35 Go d'espace de swap.

Depuis le manuel `` supérieur '':

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Compte tenu de cette explication, je m'attendrais à ce que l'allocation de mémoire virutale pour un processus soit limitée à mon swap + mémoire physique disponible.

Selon «pmap», le code, la bibliothèque partagée et les sections de mémoire partagée de ce processus sont tous minimes - pas plus de 300 Mo environ.

De toute évidence, la machine et le processus fonctionnent toujours correctement (quoique lentement), alors qu'est-ce qui me manque ici?

Il peut s'agir d'une demande de mémoire nulle qui ne se trouve pas dans le ram physique ou dans le fichier d'échange.

Quelques ressources que vous voudrez peut-être consulter:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

Votre application crée-t-elle beaucoup de pages mémoire vides? Si tel est le cas, votre application pourrait bénéficier grandement de:

• http://code.google.com/p/compcache/ ( EXPERIMENTAL )

Il vous permet de compresser et de décompresser dans les pages de mémoire en temps réel. À son tour, vous êtes capable de tout garder en RAM plutôt que d'échanger sur le disque ( très lent ).

Voici une discussion de virt vs mémoire résidente:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

La discussion se réfère aux processus Java, mais s'applique à tout ce qui fonctionne sous Linux. Le point principal en ce qui concerne la vertu est que le total comprend tout un tas de choses qui ne peuvent jamais être utilisées. Virt est quelque chose à regarder pour les systèmes d'exploitation 32 bits (car les processus atteindront des limites sur l'espace adressable), mais il est largement inutile autrement. Comme indiqué, la chose à laquelle il faut faire attention est la mémoire résidente, qui sera limitée à la RAM physique disponible et à votre swap.

Cela est probablement dû au fait que l'espace d'adressage du processus est de la taille que vous avez indiquée, mais il n'est pas vraiment alloué par le système d'exploitation.

De: http://lwn.net/Articles/428100/

Dans le processus visant à atteindre cet objectif de "temps système suffisamment faible et sans latence significative", les développeurs de Go ont fait quelques hypothèses simplificatrices, dont l'une est que la mémoire gérée pour une application en cours d'exécution provient d'une seule et virtuellement contiguë. plage d'adresses. De telles hypothèses peuvent rencontrer le même problème rencontré par votre éditeur avec vi - un autre code peut allouer des morceaux au milieu de la plage - les développeurs Go ont donc adopté la même solution: ils allouent simplement toute la mémoire dont ils pensent avoir besoin (ils ont compris, raisonnablement, que 16 Go devraient suffire sur un système 64 bits) au démarrage.

C'est donc la façon non élégante de gérer la mémoire parfois - avoir un espace d'adressage continu simplifie la libération de mem inutilisé.

La réponse est probablement MMAP - les données sont sur le disque, mais elles sont "en dehors" du swap et ne peuvent pas être vues avec la commande "free" ou "top".

Si le processus java n'est pas trop compliqué, vous pouvez essayer de jouer avec "lsof" pour trouver où se trouve le fichier MMAP. Cependant, si ce processus java est compliqué, il sera difficile d'être vu.

J'ai également été surpris que Linux vous permette d'allouer plus de mémoire virtuelle qu'il n'y a de mémoire physique + d'espace de swap, mais apparemment, cela améliore les performances dans des situations typiques.

Heureusement, il existe un paramètre de réglage du noyau qui peut être utilisé pour changer le mode de comptabilisation de la mémoire. Ce paramètre est vm.overcommit_memory et indique quel algorithme est utilisé pour suivre la mémoire disponible. La valeur par défaut (0) utilise la méthode heuristique et surcharge le système de mémoire virtuelle. Si vous souhaitez que vos programmes reçoivent des erreurs de mémoire insuffisantes lors de l'allocation au lieu de soumettre vos processus à des éliminations aléatoires, vous devez définir ce paramètre sur 2.

http://www.linuxjournal.com/article/10678