Précédent   Forum des professionnels en informatique > C et C++ > C++
C++ Forum d'entraide technique sur le langage C++. Avant de poster -> F.A.Q C++
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 07/02/2012, 17h15   #1
Membre habitué
 
Avatar de Kalite
 
Homme
Développeur informatique
Inscription : octobre 2006
Messages : 236
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations professionnelles :
Activité : Développeur informatique

Informations forums :
Inscription : octobre 2006
Messages : 236
Points : 104
Points : 104
Envoyer un message via MSN à Kalite
Par défaut [Linux] Occupation mémoire.

Bonjour,

Je voudrait savoir, un petit chose. Je suis sous un linux embarqué à chaque fois que je créer un thread la VCZ de mon programme augmente de 8192 (Je n'arrive pas à trouver l'unité). Lorsque le thread est détruit la VCZ ne diminue pas.

Il n'y a pas l'air d'avoir de fuite mémoire dans mon programme. Donc je ne comprend pas pas pourquoi ?

Merci d'avance de vos lumière.
Kalite est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 07/02/2012, 19h28   #2
Expert Confirmé
 
Avatar de DonQuiche
 
Inscription : septembre 2010
Messages : 1 350
Détails du profil
Informations forums :
Inscription : septembre 2010
Messages : 1 350
Points : 2 510
Points : 2 510
Bonjour.

Avant tout le VSZ est exprimé en ko, ton programme a donc vu sa taille augmentée de 8Mo. Voici quelques raisons pour lesquelles la taille ne diminue pas forcément :
* L'implémentation de "free" par la libc ne redonne pas systématiquement les pages libérées au système. La plupart du temps elle les garde sous le coude pour un prochain appel de malloc.
* Une biblio peut avoir été chargée par le thread. Même si celle-ci est partagée avec d'autres processus et n'a donc pas nécessité d'allocation mémoire elle sera tout de même comptabilisée par ps.
* Et, bien sûr, le thread peut avoir créé des données qui n'ont pas été détruites. Ce qui n'est pas une fuite mémoire si ces données sont utilisées par d'autres threads. Oui, j'aime bien faire mon captain obvious.
DonQuiche est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 07/02/2012, 23h12   #3
Expert Confirmé
 
Emmanuel Deloget
Inscription : septembre 2007
Messages : 1 542
Détails du profil
Informations personnelles :
Nom : Emmanuel Deloget
Âge : 36
Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

Informations forums :
Inscription : septembre 2007
Messages : 1 542
Points : 2 905
Points : 2 905
De manière générale, les ressources mémoires utilisées par un programme augmentent toujours, et ne diminue jamais. C'est une vision simpliste (cf ci-dessous).

L'implémentation traditionnelle des fonctions d'allocation mémoire utilise l'appe;l système brk() pour réserver de la mémoire en plus pour un process. Il est plus couteux de rendre cette mémoire (qui pourrait nécessiter d'être récupérée ensuite) plutôt que de la garder "au cas ou".

Bien sûr, j'ai dis que c'était une vision simpliste, elle est donc souvent fausse. Les linux récents, lorsqu'ils sont couplés à une libc récente, utilisent l'appel système mmap pour réserver de la mémoire pour les grosses allocations. Si cette mémoire n'est plus nécessaire, la rendre au système est tout à fait envisageable. Evidemment, il faut que la libc utilisée utilise cette technique pour que ça soit efficace ; dans le cas contraire, on en revient à brk().

Pour ton "problème" de VSZ, cf. http://virtualthreads.blogspot.com/2...-on-linux.html (ou tu apprendra que ce nombre, au final, ne veut pas dire grand chose).
__________________
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
Emmanuel Deloget est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 08/02/2012, 08h52   #4
Membre habitué
 
Avatar de Kalite
 
Homme
Développeur informatique
Inscription : octobre 2006
Messages : 236
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations professionnelles :
Activité : Développeur informatique

Informations forums :
Inscription : octobre 2006
Messages : 236
Points : 104
Points : 104
Envoyer un message via MSN à Kalite
Merci pour les infos. J'avai déjà lu que la VCZ ne signifiait pas grand chose. Mais quand même voir la taille augmenter de 8192ko a chaque nouveau thread sa fait bizarre car je ne fait aucune allocation dynamique au delà de 1024o.

Ce pourrait-il que ce soit la pile du thread qui soit alloué a chaque fois ?
Kalite est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 08/02/2012, 11h01   #5
Expert Confirmé
 
Avatar de DonQuiche
 
Inscription : septembre 2010
Messages : 1 350
Détails du profil
Informations forums :
Inscription : septembre 2010
Messages : 1 350
Points : 2 510
Points : 2 510
Par défaut, sous Linux, la taille de la pile est effectivement 8Mo (peut changer selon les systèmes) mais elle est de toute façon libérée lorsque le thread se termine (mais, là aussi je présume, pas forcément redonnée au système). Es-tu certain que la mémoire augmente systématiquement à chaque fois que tu détruis un thread et en recrée un autre ? Je t'invite à faire un test rigoureux avec N fermetures et ouvertures, je gage qu'au bout d'un moment la mémoire n'augmentera plus.
DonQuiche est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 10/05/2012, 16h30   #6
Membre habitué
 
Avatar de Kalite
 
Homme
Développeur informatique
Inscription : octobre 2006
Messages : 236
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations professionnelles :
Activité : Développeur informatique

Informations forums :
Inscription : octobre 2006
Messages : 236
Points : 104
Points : 104
Envoyer un message via MSN à Kalite
Je remonte le post car j'ai de nouveau élément. En effet, il semble qu'au bout de + ou - 250 connexions je n'arrive plus à lancer de thread. La valeur de blocage est la même dans top. Je n'ai fait que 2 fois le test.

Voici le retour de la commande "top":
Code :
1
2
3
4
5
6
7
8
9
  PID  PPID USER  STAT   VSZ %MEM %CPU COMMAND
  965   962  root     R     2252   8%      1% top
  634     1   root     S     2027m7032%  0% MyApp
 
et le retour de la commande "free":
                  total         used         free       shared      buffers
Mem:        29508        16876        12632        0              0
Swap:           0              0              0
Total:        29508        16876        12632
Je suis entrain de faire des tests supplémentaire pour être sûr mais il me manque la première la trace qui est au début de la routine du thread.

Edit : la fonction pthread_create retourne EAGAIN à partir du 253ème. J'utilise la fonction pthread_cancel pour terminer le thread si besoin mais je n'appel aucune fonction lorsque le thread se termine tout seul en retournant 0 sytématiquement.
Kalite est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 11/05/2012, 09h27   #7
Membre habitué
 
Avatar de Kalite
 
Homme
Développeur informatique
Inscription : octobre 2006
Messages : 236
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations professionnelles :
Activité : Développeur informatique

Informations forums :
Inscription : octobre 2006
Messages : 236
Points : 104
Points : 104
Envoyer un message via MSN à Kalite
J'ai trouvé !!

C'est simle faut juste bien lire la doc. Il est indispensable de faire un pthread_join() pour que l'ID et la stack du thread soit réutilisable.
Kalite est déconnecté   Envoyer un message privé Réponse avec citation 10
Réponse Proposer ce sujet en actualité Cette discussion est résolue.
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 18h52.


 
 
 
 
Partenaires

Hébergement Web