Discussion :

[yann458]

Bonjour,

Je suis sur un projet ,qui utilise beaucoup de pointer.
Quand ma mémoire arrive à saturation , l'allocation échoue bien évidemment.
Le hic , c'est quand je libère la mémoire , je vois pourtant bien dans le gestionnaire de tache que la mémoire utilisé diminue
une allocation mémoire demandé de 700 Mb échoue avec l'exception "Out of memory" sachant qu'il reste environ 2Gb de mémoire disponible et que à ce moment là ,mon projet n'utilise que 500 Mb de mémoire.
En passant par la méthode new et free , j'ai essayer la fonction VirtualAlloc pour les 700 Mb , même soucis.

Comment résoudre ce problème ?

Merci.

[foetus]

Ou là
Chaque application se voit allouer une "portion de mémoire" par le système d'exploitation: donc ton ordinateur peut avoir 2, 4, 12, 24 Gigas en mémoire centrale, mais ton application maximum 1 ou 2 Gigas

Dis-nous ton système d'exploitation et surtout s'il est 32 ou 64 bits?

Édit: Un papier d'Intel de 2011 peut-être pas pertinent, mais qui montre le problème: Memory Limits for Applications on Windows

[ternel]

En passant par la méthode new et free

Mes yeux saignent... new et delete, ou bien malloc et free. Ne jamais mélanger les deux types d'allocation.

ps: je sais, c'est un jamais d'informaticien...

[Médinoc]

Et aussi, new[] et delete[]. Trop d'apprentis programmeurs ne connaissent même pas l'existence de delete[].

[isangoma]

Bonjour,

J'avais eu un probleme similaire il y a quelques temps avec un programme en developpement qui pouvait demander jusqu'a 10GO de memoire.
Ma solution fut de compiler en 64bits.

[jblecanard]

Hello

la première chose à faire dans ce genre de cas, c'est de passer un memory checker pour voir s'il y a des fuites, et où. Une fois les fuites corrigées (c'est vite dit mais c'est pas forcément facile au contraire !), à ce moment là seulement il faudra t'intéresser à d'autres stratégies pour économiser la mémoire.

[jabbounet]

hormis les problèmes de limite par applications cités précédemment, il faut aussi regarder comment ta ram est fragmentée...

plus précisément si ton programme fait une grosse allocation de 700 Mo avec un seul malloc/realloc (façon C) ou new (façon C++), et si ma mémoire est bonne, le système dans ce cas cherchera un bloc de mémoire contiguë de 700 Mo. donc même s'il te reste 2 Go de ram, si la fragmentation de ta RAM fait qu'il n'y a pas de zone contiguë suffisamment grande pour recevoir ta demande d'allocation elle échouera.


Ceci dit quand un programme consomme beaucoup de mémoire il faut regarder s'il n'y a pas de duplication de données inutile, et regarder les fuites éventuelle avec un programme comme valgrind par exemple.

[skeud]

Je suis le seul que ça choque une allocation de 700M?

Normalement, une application bien pensée ne devrait pas avoir besoin d'allouer autant d'un coup. Qu'une application consomme 700M fragmenter en plein de petit morceau, je trouve ça normal, mais 700M d'un coup ........

Peut-être faut-il voir pour changer ce fonctionnement, si c'est des ressource, on peut très bien passé par un file-mapping ou autre technique du genre pour allouer les 700M sur le disque et non pas en ram.

[_zzyx_]

Une allocation de 700 MB ca ne me choque pas plus que ça,
ça correspond à un peu plus qu'un tableau de 512x512x512 entiers

Bien sur ça peut souvent se cacher sur disque, mais
Les lectures/écritures sur disques sont plus lente qu'en RAM, donc ça réduit l’intérêt d'avoir une machine rapide et un algo optimisé. Surtout que la RAM c'est pas cher
Certaines opérations peuvent demander d’accéder à des cases non voisines du tableau ce qui multiplierait pas autant le temps de lecture sur disque
Pourquoi emmerder avec un système de cache pour quelques chose qui prend quelques pour-cents de la RAM totale

évidemment sur un système embarqué avec peu de ram et un disque SSD c'est différend
évidemment si il ne faut faire qu'une opération sur le tableau ça ne sert à rien de l'avoir en entier en mémoire.
Mais si il faut par exemple le transformer en ondelette, filtrer l'information à une certaine échelle puis revenir dans l'espace direct, Cacher les données sur disque ne servira qu'à perdre du temps

[the Hound]

hormis les problèmes de limite par applications cités précédemment, il faut aussi regarder comment ta ram est fragmentée...

plus précisément si ton programme fait une grosse allocation de 700 Mo avec un seul malloc/realloc (façon C) ou new (façon C++), et si ma mémoire est bonne, le système dans ce cas cherchera un bloc de mémoire contiguë de 700 Mo. donc même s'il te reste 2 Go de ram, si la fragmentation de ta RAM fait qu'il n'y a pas de zone contiguë suffisamment grande pour recevoir ta demande d'allocation elle échouera.


Ceci dit quand un programme consomme beaucoup de mémoire il faut regarder s'il n'y a pas de duplication de données inutile, et regarder les fuites éventuelle avec un programme comme valgrind par exemple.

La fragmentation de la ram c'est des c****ries ...
A moins que tu travailles sur un système vieux de vingt ans, les applications tournent dans un environnement virtuel dans lequel la ram "telle que vue par le programme" est contiguë.
Tu peux très bien allouer 700Mo de mémoire vive, totalement fragmentée, et pourtant avoir un bloc contigu de 700Mo de ram (vu par le programme).
http://en.wikipedia.org/wiki/Memory_management_unit

[Médinoc]

Mais ici, le problème est justement dans l'espace mémoire plutôt que la RAM.
2GO, c'est la quantité d'espace mémoire disponible à un processus user-mode sous un Windows 32 bits (hormis mode 3GO + /LargeAddressAware).

Et l'espace mémoire lui, souffre de la fragmentation.

[Astraya]

Salut

Comme le dis Médinoc, la virtualisation de la mémoire ne veux pas dire qu'elle n'est pas fragmenté, ça veux dire qu'elle fait croire au programme que le bloc 0,1,2,3...X est contigüe.

Si tu utilises beaucoup de pointeur, le mieux est de réservé un bloc de sizeof(X) pointeur et de placement new dessus. Tu peux allez encore plus loin en allouant un énorme bloc (1-2Go, voir plus su 64bits), et les fragmenté tout même en plus petit bloc indépendant qui ont chacun leur utilité. Comme ça, tu alloues un fois et utilise X fois, si tu fais de nombreux new/delete c'est très rentable.

[jouana]

Bonjour,

Pour une taille pareil tu peux, peu être te tourner vers mmap, augementer la taille de ram que ton programme va utiliser.

Après j'ai fais des programmes plutôt gourmand en RAM a cause d’enchaînement d’état en tout genre et la je me suis orienté sur des tableaux de masques binaires.

Il est important de bien penser à ta structure de données.

Vu la taille que tu alloue d'un coup je pense plus à un fichier.
t'est-il neccessaire d'avoir tout le fichier en mémoire, si c'est le cas alors utilise mmap qui est fait pour ça.

Bonne journée

[the Hound]

Pour une taille pareil tu peux, peu être te tourner vers mmap, augementer la taille de ram que ton programme va utiliser.

Il a utilisé VirtualAlloc(), donc c'est un environnement Windows, mmap() n'existe pas.

[Médinoc]

Mais son équivalent existe.

Ce qui n'avance pas à grand-chose si le problème est la consommation d'espace d'adressage et non de RAM. Dans tous les cas, cette méthode implique de ne pas mémoriser/mapper tout le fichier d'un coup (et donc, de faire plus ou moins son propre paging).

Edit: Ou bien, passer en 64 bits.