RE : RE : [Tsp-devel] Increasing memory while sampling

[ALAUX, Virginie]

Bonne nouvelle:

Avec top, c'est seulement la colonne "RES" qui augmente pendant le sampling 
pendant un certain temps (~=> jusqu'à 33/36 Mega) puis reste stable, la "VIRT" 
reste stable.
RES redescend à l'appel du sample_destroy
Si on refait un restart acq "sample_init": RES remonte de la même façon que 
pour le premier sampling.

Le fait que les 2 augmentaient (RES et VIRT), et que pour le 2eme sample_init, 
ça restait stable vient de valgrind; car je passais les tests avec valgrind 
pour détecter les memory leak.

J'ai donc fait un petit test de robustesse (sampling pendant 3 heures ) : c'est 
OK, ca augmente au début (36Mega) puis ça reste stable...

Merci pour vos conseils...
A+

Virginie Alaux (55-24)


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of ALAUX, Virginie
Sent: Tuesday, July 31, 2007 10:16 AM
To: 'Transport Sample Protocol development list'
Subject: RE : [Tsp-devel] Increasing memory while sampling




Bonjour,

J'ai passé massif sur mon programme, je joins le .ps généré.
Je travaille sur Linux avec TSP.0.8.3 avec patch bug 19706
Je suis en train d'essayer de créer un programme qui ferait seulement du tsp 
(même utilisation que le code de mon projet qui pose problème) et voir si le pb 
se reproduit; dans ce cas, je vous ferai parvenir ce code...

A+

Virginie Alaux (55-24)


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Eric Noulard
Sent: Monday, July 30, 2007 1:59 PM
To: Transport Sample Protocol development list
Subject: Re: [Tsp-devel] Increasing memory while sampling


Le 30/07/07, Frederik Deweerdt<address@hidden> a écrit :
> On Mon, Jul 30, 2007 at 11:04:25AM +0200, Eric Noulard wrote:
> > D'après ce que je comprends la conso mémoire l'ascii_writer
> > ne souffre pas d'inflation mais est maximum peu après request_sample_init
> > puis tombe à 0 en fin d'exécution.
> >
> > Fred, peux-tu confirmer/corriger mon analyse?

> Hmm, c'est bien ce que donne massif: il y a enormement d'allocs qui se
> passent au dÃ(c)but du programme, puis celle-ci cessent parla suite.

> Est-ce qu'on pourrait avoir le problème suivant:
> 1) RINGBUF_PTR_INIT alloue beaucoup de mÃmoire en dÃ(c)but de programme:
> cf: http://www.mail-archive.com/address@hidden/msg00480.html
> - massif rapporte une alloc de 1Go!

Je vais ajouter de quoi STRACER les allocations des RINGBUFs
d'ailleurs je pense qu'on pourrait avantageusement remplacer
tous les malloc/calloc par un tsp_alloc de façon à pouvoir
maîtriser/monitorer toutes les allocations dynamiques via une seule
fonction de la lib TSP.

> 2) L'allocation marche, mais les pages ne sont utilisÃ(c)es effectivement
> qu'au fur et a mesure, du coup on a l'impression que les allocations se
> font de manière continue et a un rythme elevÃ(c).

C'est possible.
Je m'en vais ajouter un mlockall histoire de voir si ça me pète à la tronche.

> 3) On n'aurait pas de problème de fuite mÃ(c)moire mais juste un ring
> buffer trop gros en comparaison avec ce dont on a rÃ(c)ellement besoin?

Oui, possible.
J'avais déjà limité la taille de certains buffers à 2 Mo.
https://savannah.nongnu.org/bugs/index.php?16629

Je vais voir ce que je peux faire pour le ringbuf.
Ce qui est étonnant c'est qu'un deuxième tsp_sample_request_init
stoppe le phénomène.

Mais bon ce n'est peut-être qu'un épiphénomène.

-- 
Erk


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel



Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des 
informations confidentielles et/ou protegees ou dont la diffusion est 
restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le 
copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en 
avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. 
Astrium decline toute responsabilite en cas de corruption par virus, 
d'alteration ou de falsification de ce courriel lors de sa transmission par 
voie electronique.

This email (including any attachments) may contain confidential and/or 
privileged information or information otherwise protected from disclosure. If 
you are not the intended recipient, please notify the sender immediately, do 
not copy this message or any attachments and do not use it for any purpose or 
disclose its content to any person, but delete this message and any attachments 
from your system. Astrium disclaims any and all liability if this email 
transmission was virus corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium SAS (393 341 516 RCS Paris) - Siege social: 6 rue Laurent Pichat, 75016 
Paris, France

Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des 
informations confidentielles et/ou protegees ou dont la diffusion est 
restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le 
copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en 
avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. 
Astrium decline toute responsabilite en cas de corruption par virus, 
d'alteration ou de falsification de ce courriel lors de sa transmission par 
voie electronique.

This email (including any attachments) may contain confidential and/or 
privileged information or information otherwise protected from disclosure. If 
you are not the intended recipient, please notify the sender immediately, do 
not copy this message or any attachments and do not use it for any purpose or 
disclose its content to any person, but delete this message and any attachments 
from your system. Astrium disclaims any and all liability if this email 
transmission was virus corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium SAS (393 341 516 RCS Paris) - Siege social: 6 rue Laurent Pichat, 75016 
Paris, France