Projet

Général

Profil

Anomalie #260

fuite mémoire loi anisotropie par projection

Ajouté par Julien Troufflard il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.

Statut:
Résolu
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
14/09/2020
Echéance:
% réalisé:

100%

Temps estimé:

Description

Gérard,

j'ai constaté un problème de fuite mémoire qui m'empêche de mener un calcul de coussin gonflable. Je suis à peu près certain que le problème vient de là puisque le calcul s'arrête sans générer d'erreur Herezh++. Le processus est tout simplement killed. Cela est aléatoire, autrement dit un même calcul plante à une certaine itération de relaxation dynamique mais tout à fait planter à une autre itération si je le relance. A mon avis, cela dépend de l'occupation mémoire de la machine.

Je te joins un calcul isotrope (coussin_isotrope.info) et un calcul anisotrope (coussin_anisotrope.info).

Dans le cas isotrope, j'ai sur ma machine une occupation mémoire de 98M qui reste constante.
Dans le cas anisotrope, j'ai noté une occupation mémoire qui évolue au cours des itérations :
IT 1 : 148M
IT 5 : 165M
IT 10 : 185M
IT 15 : 208M
IT 20 : 232M
IT 25 : 261M
IT 30 : 286M
IT 45 : 381M
(rq : une traçage gnuplot de ces données montre que la relation IT-mémoire est linéaire)

j'aimerais passer ce calcul anisotrope pour le rapport R&T de septembre. J'espère que c'est bien ça le pb et qu'il sera facile à résoudre.


Fichiers

pb_fuiteMem_anisotropie.tar (143 ko) pb_fuiteMem_anisotropie.tar Julien Troufflard, 14/09/2020 10:14
#1

Mis à jour par Frank Petitjean il y a plus de 4 ans

Je vais essayer sur mon PC de course, c'est quand même autre chose qu'un Mac ;-)
Frank

#2

Mis à jour par Gérard Rio il y a plus de 4 ans

  • Statut changé de Nouveau à En cours
  • % réalisé changé de 0 à 80

oui c'est bien vue !!
j'ai trouvé la raison et je met à jour dans la version 6.955...
dit moi si c'est ok

#3

Mis à jour par Julien Troufflard il y a plus de 4 ans

Frank : c'est sur linux que j'ai constaté le pb. Laisse donc tranquille les mac :)

Gérard : merci pour le correctif. J'attends la version linux pour lancer mon calcul

#4

Mis à jour par Frank Petitjean il y a plus de 4 ans

La version isotrope est passée en moins de 30min et je viens de lancer le cas anisotrope. Je bosse comme toi sous Linux/windows.
J'arrête donc le job et bravo à Gérard d'avoir vu si vite le pb !
Frank

#5

Mis à jour par Julien Troufflard il y a plus de 4 ans

Gérard : c'est ok avec la version linux. L'occupation mémoire est constante désormais.

merci Frank d'avoir testé des trucs.
mon linux n'a que 16 Go de RAM (CPU 2.8 GHz) mais ça reste ma machine la plus performante. Le calcul que j'ai mis dans ce ticket est en loi élastique. Mais le vrai est avec loi HH et, dans le cas isotrope, il a mis 18h. Je m'attend donc à 2.5 fois ce temps avec loi anisotrope.

#6

Mis à jour par Julien Troufflard il y a plus de 4 ans

ps : bon, néanmoins on s'en fout un peu de la RAM. Ce calcul ne nécessite que 1% de cette RAM. Le vrai point bloquant est le CPU et le fait de ne pouvoir utiliser qu'un seul de ces CPU sur les 8 de ma machine.

#7

Mis à jour par Frank Petitjean il y a plus de 4 ans

Oui la mémoire est très peu sollicitée (calcul explicite ?). Mon processeur tourne à 2.90 HHz et j'ai 16 CPU avec 32Go de RAM. A quand la version parallèle ? Par Walter dans une future version OpenSource ?

#8

Mis à jour par Gérard Rio il y a plus de 4 ans

  • Statut changé de En cours à Résolu
  • % réalisé changé de 80 à 100

parfait,
je ferme le ticket.
Pour info, il ne faut trop rêver, on aura toujours envie d'aller plus vite que l'existant, et dans cette course la parallélisation est un outil de base intéressant mais qui ne remplace pas une réflexion plus théorique et analytique...

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux