[presque résolu] comment profiler la mémoire

dva2tlse · Le 11/09/2013, à 11:14

Bonjour le forum,
quelqu'un saurait-il comment faire pour surveiller la quantité de mémoire qu'utilise un programme à différents moments.
En effet, j'ai commencé à paralléliser un programme avec openMP, et il fonctionne assez bien sur deux threads; mais dès que j'essaye d'en utiliser plus, il se produit une "Memory fault" (et non pas une "Segmentation fault", dont je saurais où chercher la cause)
Donc je voudrais surveiller la mémoire qui est utilisée à différents moments, afin de connaître les possibilités éventuelles d'augmenter le nombre de threads qui travaillent pour aller plus vite tant qu'il resterait de la mémoire disponible.
Merci,
David

Dernière modification par dva2tlse (Le 13/09/2013, à 17:54)

timtamtom · Le 11/09/2013, à 17:29

Salut,
tu peux essayer les commandes top et htop pour voir l'activité des processus en direct
ctrl+M pour les classer par conso de mémoire décroissante

la doc ici: http://rstatistique.blogspot.fr/ #paragraphe 2.9
ou en faisant man top

Dernière modification par timtamtom (Le 11/09/2013, à 17:30)

dva2tlse · Le 11/09/2013, à 17:36

merci timtamtom,
j'ai besoin d'avoir une trace des contrôles effectués, donc les top et htop et free et même ps ne me conviennent pas et c'est pourquoi j'ai posé la question ici. (pas de façon assez précise cependant)
merci encore,
David

claudius01 · Le 12/09/2013, à 09:01

Bonjour,

Peut-être que le très complet proc - process information pseudo-file system répond à ton problème.
Utilisable de l'extérieur ou de l'intérieur d'un programme (voire du programme lui-même qui peut "s'auto analyser" ;-) dès lors que le pid du process à analyser est connu et que tu as un accès root au système.

Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 12/09/2013, à 09:04)

dva2tlse · Le 12/09/2013, à 11:45

Bonjour Claudius01,
j'ai parcouru le texte vers lequel envoie le lien que tu as posté ci dessus, et j'avoue que ça me paraît un peu compliqué; de plus je n'ai même pas réussi à voir de choses qui concerneraient la mémoire, même s'il y en a probablement parce que ça à l'air très riche. Cependant ceci est pour mon boulot et je n'ai pas d'accès root légal, donc ce n'est pas un bais que j'approfondirai.
Merci,
David
PS: je reste preneur de tout moyen qui me permettrait de contrôler en temps réel la mémoire qu'utilise mon programme en différents endroits. J'ai lu mais je ne sais plus où, qu'il existait des fonctions qui permettent de le faire, mais peut-être pas en gfortran de GNU.

Dernière modification par dva2tlse (Le 12/09/2013, à 16:36)

claudius01 · Le 12/09/2013, à 12:42

Re,

Ok, s'agissant des droits d'accès root, certains points d'entrées de /proc/<pid_process> ne le nécessitent pas comme 'status' qui fournit pas mal d'informations concernant la mémoire (ici appliqué à xclock) :

$ cat /proc/2229/status
Name:   xclock
State:  S (sleeping)
Tgid:   2229
Pid:    2229
PPid:   2106
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 256
Groups: 4 24 27 30 46 109 124 1000 1001 
VmPeak:    65144 kB
VmSize:    65140 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      3892 kB
VmRSS:      3536 kB
VmData:      696 kB
VmStk:       136 kB
VmExe:        36 kB
VmLib:      6752 kB
VmPTE:       140 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/7815
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        13766
nonvoluntary_ctxt_switches:     17

Edit: Un fil de discussion en rapport avec ce même sujet : cf. taille d'un process

Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 12/09/2013, à 13:23)

grim7reaper · Le 12/09/2013, à 13:33

Salut,

Si tu est sous Linux, je plussoie l’idée de passer par le système de fichier virtuel procfs.
Il n‘y a pas besoin d’avoir les droits de root pour lire les informations que tu cherches.
De plus, tu n’as pas besoin de connaître le PID de ton programme grâce au très pratique raccourci self.
Quand au fichier à lire, je te conseille statm.
Un petit exemple rapide :

PROGRAM main
  IMPLICIT NONE

  INTEGER, PARAMETER :: statm = 42 ! statm logical unit.
  INTEGER :: ios    ! I/O status
  INTEGER :: VmSize ! total program size.
  INTEGER :: VmRSS  ! resident set size.
  INTEGER :: share  ! shared pages (from shared mappings).
  INTEGER :: text   ! text (code).
  INTEGER :: lib    ! library (unused in Linux 2.6).
  INTEGER :: stack  ! data + stack.
  INTEGER :: dt     ! dirty pages (unused in Linux 2.6).

  OPEN(statm, file='/proc/self/statm', iostat=ios, status='old', &
       access='sequential', action='read')
  IF (ios /= 0) THEN
    PRINT *, 'Cannot open /proc/self/statm'
    STOP
  END IF

  READ(statm, *) VmSize, VmRSS, share, text, lib, stack, dt

  PRINT *, 'VmSize'      , VmSize
  PRINT *, 'VmRSS'       , VmRSS
  PRINT *, 'Shared pages', share
  PRINT *, 'Code'        , text
  PRINT *, 'Library'     , lib
  PRINT *, 'data + stack', statm
  PRINT *, 'Dirty pages' , dt

  close(statm)
END PROGRAM

L’occupation mémoire est mesuré en page.
Une page fait généralement 4Ko, mais pour le vérifier tu peux faire :

getconf PAGESIZE

dans un terminal (si PAGESIZE ne fonctionne pas, essaye PAGE_SIZE).

Dernière modification par grim7reaper (Le 12/09/2013, à 13:37)

dva2tlse · Le 12/09/2013, à 14:14

OOUAFFF, merci; ça c'est du costaud et la man est parfait comme d'hab', merci.
En effet je bosse sous linux, donc mon programme va voir un ou deux petits "open" supplémentaires pour lire ces infos.
Merci encore,
David

grim7reaper · Le 13/09/2013, à 06:30

Si ton problème est résolu, pense à passer le sujet en résolu
Ça aidera les gens qui ont le même problème que toi

dva2tlse · Le 13/09/2013, à 17:52

Bonsoir grim7reaper,
mon problème n'est pas tout à fait résolu; il a simplement avancé, puisque gdb a fini par accepter de me dire quelle ligne du quelle subroutine faisait tout planter. J'étais en train de paralléliser un gros (pour moi) programme en fortran, et celui ci donnait de très bons résultats quand je l'utilisais de façon séquentielle ou sur deux threads, mais il plantait toujours sur quatre threads et parfois sur trois; donc pour trouver l'erreur je lui ai imposé de tourner sur quatre threads, et la "Memory fault" que j'obtenais, et dont je croyais qu'elle était un manque de mémoire dû à la "gourmandise" de mes quatre threads, donc, cette erreur s'est révélée être une "simple" segfault d'après ce que m'a dit gdb.
Donc je suis décoincé pour l'instant, et cela grâce à des "call system('cat /proc/self/status | grep Vm', entier_résultat), qui m'ont montré que mon programme ne consommait pas toute la mémoire de la machine comme je le croyais.
Par contre, et c'est une question qui a été posée plus haut dans le fil et à laquelle j'aimerais bien connaître la réponse, quelle est la fréquence de rafraichissement de ces données; et est il judicieux, comme je l'avais fait avant les 'cat /proc/self/status | grep Vm', d'ouvrir et refermer, et réouvrir ce fichier pour y lire de nombreuses fois ce qui m'intéresse ?
Merci,
David

grim7reaper · Le 13/09/2013, à 19:43

Bonsoir,

dva2tlse a écrit :

cette erreur s'est révélée être une "simple" segfault d'après ce que m'a dit gdb.

C’est ce qu’il me semblait aussi, mais n’étant pas sûr de moi je n’ai préféré rien dire au cas où je t’aurais orienté dans une mauvaise direction.

dva2tlse a écrit :

quelle est la fréquence de rafraichissement de ces données;

Il n’y en a pas, c’est une vision temps réel si je puis dire.
Il faut bien voir que procfs c’est un système de fichier virtuel. Et les fichiers qui s’y trouvent ne sont ni sur ton disque ni dans ta RAM.
D’ailleurs si tu regardes la taille des fichiers dans /proc, tu vas voir que 99% d’entre eux ont une taille nulle ^^
En fait, les données que tu lis dans ces fichiers sont générées à la volée lorsque tu y accèdes, afin de te donner une information en temps réel sur l’état du système.

dva2tlse a écrit :

et est il judicieux, comme je l'avais fait avant les 'cat /proc/self/status | grep Vm', d'ouvrir et refermer, et réouvrir ce fichier pour y lire de nombreuses fois ce qui m'intéresse ?

En l’occurence oui c’est bien la bonne façon de faire (encore que lancer une commande externe est sûrement bien plus coûteux que de lire le fichier directement depuis Fortran).
Étant donné que les informations sont générées à la volée à chaque accès, quand tu veux une nouvelle valeur il faut réacceder au fichier (donc réouvrir le fichier oui).

claudius01 · Le 14/09/2013, à 18:04

Bonsoir,

dva2tlse a écrit :

dva2tlse
... cette erreur s'est révélée être une "simple" segfault.

Je crains que l'origine soit un accès concurrent à une zone critique qui n'est pas protégée par verrou.
Maintenant, est-ce que la pile d'appel depuis la méthode main (en langage C car je ne sais pas comment elle s'appelle en Fortran ;-) est "lisible et cohérente" ou si celle-ci est au contraire "corrompue" auquel cas cela ne va pas être facile à trouver...
Par expérience, cela passe par une relecture de code approndie en vérifiant systématiquement si TOUTES les méthodes et zones utilisées dans ces parties critiques sont thread safe.

Bon courage...

Edit: Correction thread safe

Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 16/09/2013, à 09:04)

grim7reaper · Le 15/09/2013, à 06:53

claudius01 a écrit :

ces parties critiques sont thread self.

Je pense que tu voulais dire thread safe

claudius01 · Le 16/09/2013, à 09:05

Bonjour à tous,

grim7reaper a écrit :

Je pense que tu voulais dire thread safe

Oups. Effectivement c'est bien thread safe
Merci grim7reaper pour cette coquille que je m'en vais corriger de suite.

Cordialement, A+
--
Claudius

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/09/2013, à 11:14

[presque résolu] comment profiler la mémoire

#2 Le 11/09/2013, à 17:29

Re : [presque résolu] comment profiler la mémoire

#3 Le 11/09/2013, à 17:36

Re : [presque résolu] comment profiler la mémoire

#4 Le 12/09/2013, à 09:01

Re : [presque résolu] comment profiler la mémoire

#5 Le 12/09/2013, à 11:45

Re : [presque résolu] comment profiler la mémoire

#6 Le 12/09/2013, à 12:42

Re : [presque résolu] comment profiler la mémoire

#7 Le 12/09/2013, à 13:33

Re : [presque résolu] comment profiler la mémoire

#8 Le 12/09/2013, à 14:14

Re : [presque résolu] comment profiler la mémoire

#9 Le 13/09/2013, à 06:30

Re : [presque résolu] comment profiler la mémoire

#10 Le 13/09/2013, à 17:52

Re : [presque résolu] comment profiler la mémoire

#11 Le 13/09/2013, à 19:43

Re : [presque résolu] comment profiler la mémoire

#12 Le 14/09/2013, à 18:04

Re : [presque résolu] comment profiler la mémoire

#13 Le 15/09/2013, à 06:53

Re : [presque résolu] comment profiler la mémoire

#14 Le 16/09/2013, à 09:05

Re : [presque résolu] comment profiler la mémoire

Pied de page des forums