Comment voir Linux point de vue de la RAM afin de déterminer la fragmentation

Le seul programme que je connaisse est pmap, mais ce n'imprime que la mémoire d'un processus.

Je voudrais voir comment la mémoire physique est occupé et par quels processus/de la bibliothèque, y compris le noyau, de la totalité de la RAM physique (par opposition à celle du processus' POV avec pmap).

Idéalement avec une interface graphique.

Savez-vous si il y a un tel outil?

Je sais à propos de l'ambiguïté introduite par les bibliothèques. Si c'est le cas, il pourrait afficher une de 1 pixel de large ligne et une flèche à l'emplacement réel de la bibliothèque.

De quoi ai-je besoin pour? Pour afficher la RAM de la fragmentation.

  • Pourquoi voudriez-vous voir cela? À moins que vous développiez code du noyau ou ont un système NUMA il ne devrait pas être important. Vous êtes peut-être à confusion physique de fragmentation de la mémoire avec la fragmentation de la mémoire présenté par l'espace utilisateur allocateurs de mémoire?
  • Non, je ne suis pas confus quoi que ce soit. Je dois dire que les 2 go de RAM sur mon système, je veux voir comment cette puce est vraiment utilisé par le noyau. Je veux juste le voir, qui sait quelles questions peuvent être soulevées à la suite.
  • Ah, l'apprentissage pour l'apprentissage de souci 🙂 +1
  • il est appelé à explorer 🙂
InformationsquelleAutor Flavius | 2011-02-01
  1. 32

    Fragmentation De La Mémoire

    Lorsqu'un système Linux a été en cours d'exécution pendant un certain temps la fragmentation de la mémoire peut augmenter qui dépend fortement de la nature des applications qui sont en cours d'exécution sur elle. Plus le processus d'allouer et de libérer de la mémoire, le plus rapide de la mémoire est fragmentée. Et le noyau ne peut pas toujours être en mesure de défragmenter assez de mémoire pour une taille demandée sur le temps. Si cela se produit, les applications peuvent ne pas être en mesure d'allouer plus contigus des morceaux de mémoire, même si il ya suffisamment de mémoire disponible. En commençant avec le noyau 2.6, c'est à dire RHEL4 et SLES9, gestion de la mémoire s'est considérablement améliorée et la fragmentation de la mémoire a de moins en moins un problème.

    De voir une fragmentation de la mémoire vous pouvez utiliser le magic SysRq key. Il suffit d'exécuter la commande suivante:

    # echo m > /proc/sysrq-trigger

    Cette commande de vidage de la mémoire actuelle de l'information de /var/log/messages. Voici un exemple d'un RHEL3 système 32 bits:

    Jul 23 20:19:30 localhost kernel: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1952kB)
Jul 23 20:19:30 localhost kernel: 1395*4kB 355*8kB 209*16kB 15*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 12244kB)
Jul 23 20:19:31 localhost kernel: 1479*4kB 673*8kB 205*16kB 73*32kB 21*64kB 847*128kB 473*256kB 92*512kB 164*1024kB 64*2048kB 28*4096kB = 708564kB)

    La première ligne indique DMA fragmentation de la mémoire. La deuxième ligne montre une Faible fragmentation de la Mémoire et de la troisième ligne montre une Forte fragmentation de la Mémoire. La sortie indique la fragmentation de la mémoire dans la Faible zone de Mémoire. Mais il y a beaucoup de grands segments de mémoire disponible dans la zone de Mémoire, par exemple, 28 (4 MO).

    Si la mémoire de l'information n'a pas été sous-évaluées dans /var/log/messages, puis SysRq n'a pas été activée. Vous pouvez activer SysRq par la mise en sysrq à 1:

    # echo 1 > /proc/sys/kernel/sysrq

    De départ avec le noyau 2.6, c'est à dire RHEL4 et SLES9, vous n'avez pas besoin SysRq pour vider la mémoire de l'information. Vous pouvez simplement cocher /proc/buddyinfo de fragmentation de la mémoire.

    Ici est le résultat d'un serveur 64 bits exécutant le noyau 2.6:

    # cat /proc/buddyinfo

Node 0, zone DMA 5 4 3 4 3 2 1 0 1 1 2
Node 0, zone Normal 1046 527 128 36 17 5 26 40 13 16 94
# echo m > /proc/sysrq-trigger
# grep Normal /var/log/messages | tail -1
Jul 23 21:42:26 localhost kernel: Normal: 1046*4kB 529*8kB 129*16kB 36*32kB 17*64kB 5*128kB 26*256kB 40*512kB 13*1024kB 16*2048kB 94*4096kB = 471600kB
#

    Dans cet exemple j'ai utilisé SysRq à nouveau pour montrer ce que chaque nombre dans /proc/buddyinfo fait référence.

    Source: http://www.puschitz.com/pblog/

    • Un détail d'importance: applications ne pas allouer des blocs de mémoire contigus de toute façon, ils ont accès à la mémoire virtuelle que. Seul le noyau a besoin de contiguë des blocs physiques - et c'est là que la RAM physique fragmentation peut être un problème.
    • Voici un petit test pour vérifier: char *p = malloc(256 * 1024 * 1024); Il devrait réussir assez bien sur la plupart des systèmes modernes, tant qu'ils ne sont pas sur le bord de la mémoire exaustion.
    • Lazarenko: Merci, +1. @thkala: Merci +1
    • Hmmm... techniquement parlant, vous avez également besoin d'un memset() appel ou quelque chose pour éviter de overcommiting...
    • certains userspace demandes pourrait devoir de mémoire contiguë, un exemple sont AF_UNIX dgram/seqpacket envoie, voir stackoverflow.com/questions/4729315/...
    • vrai, il y a assez peu de noyau de services qui ont besoin de grandes contiguë allocations - qui est pourquoi compactage de la mémoire a été introduit dans linux 2.6.35. Certains d'entre eux sont même en raison de code cassé - il y a quelques temps j'avais pour déboguer un V4L pilote à l'aide de kmalloc au lieu de vmalloc pour son mémoire tampon vidéo...
    • O_O c'était donc probablement s'écraser très souvent, n'est-ce pas?
    • disons simplement que je n'avais pas vu autant de Oops messages depuis quelques temps...

    InformationsquelleAutor