Salut,
 
Je cherche la taille maximal de memoire alloué a un processus sous Windows XP pro SP2  / 32 Bit.
 
On utilise Visual C++ au boulot
 
Merci d'avance pour votre aide.

2Gb?

j'ai entendu dire dans je ne sais plus quel article que c'etait 2gb aussi ... mais j'aimerais un avis formel.
 
On a un soft qui plante des qu'il atteint 1.1 / 1.2 gb en ram et je pensais qu'on aurait de la marge jusqu'a 2Gb (test effectué sur une becane avec 2 gb et une autre avec 4gb)

oublie pas que t'as d'autres process qui consomment de la mémoire aussi...

LePhasme:
je suis d'accord avec toi ... mais sur mon systeme avec 4Go ... il n y avait pas grand chose qui tournait a part notre applicatif.
 
Et j'ai eu la meme punition qu'avec 2 Go, blocage a 1.1 / 1.2 Go
 
J'ai monitoré la taille du processus avec le task manager
 
 

personne d'autre ?

Regarde plutôt du coté de process explorer pour monitorer des processus sous Windows. L'inutilité abyssale de TaskManager n'étant plus à prouver, Process Explorer pourra te montrer tout un tas d'autres infos, sources de problèmes potentiels : virtual memory, leak de handles, etc ....
 
Edit : sinon ton appli c'est plutôt du genre usine à gaz à faire des milliards d'allocations à gauche à droite et à libérer ça sans trop savoir quand (avec tous les emmerdes associées : fragmentation, leak), ou c'est du genre à allouer de gros bloc ?

tpierron:
Voici un topo:
 
l'executable, appelons le test.exe pese en lui meme un truc du genre 350 Ko
 
Une fois lancé, je suppose qu'il charge tout un tas de .dll qui le font peser 35Mo en mode IDLE
 
Cette executable sert a afficher des images de radiologie qui peuvent etre tres lourd (genre 8 à 16 images de 54 Mo chacune)
 
manque de chance, avec un certain examen radiologique particulierement big, je vois la quantité de memoire grimper de 35Mo jusqu'a 1.1 / 1.2 Go et mon appli me pond un "memoire insuffisante"
 
En gros, je sais deja pourquoi j'ai ce bug, au lieu de charger les "pixels data" des images une seule fois, il peut arriver que je les charges plusieurs fois en RAM.
 
Vu que mes "Pixel data" pese 400 Mo par defaut, si j'ai un bug qui charge le tout plusieurs fois en ram ... c'est normal que ca plante.
 
Le bug du "multiple loading" des pixel data est en cours de resolution, il n'empeche que dans certains cas extremes, je peux avoir des examens radiologique qui peseront "par defaut" 1.2 go.
 
Vu le pkoi du comment de ma question concernant la taille maximale d'un executable en memoire.
 
J'ai été voir dans les propriété de l executable pour essayer de changer le "mode de compatibilité" qui est par defaut Win 95 et ca ne change rien.

Ca ne répond pas vraiment à la question que tu poses, mais as-tu rééllement besoin de toutes les données en mémoire à la fois?
Tu ne pourrais pas implémenter une solution de streaming? (C'est utilisé avec un certains succès dans les jeux à "monde ouvert" )

IrmatDen:
 
malheuresement, je dois loader toutes les pixel data d'un seul coup car je dois pouvoir faire des operations en temps reel sur ces images (Zoom, fenetre / window level)
 
Par contre, de plus, a terme, je vais devoir loader non seulement les pixel data d'un patient en cours ( en moyenne 200 Mb / max 800Mb) mais aussi les pixels data de 5 autres patients

mets un windows 64 et recompile ton app en 64bits.

C'est pas la taille de l'exécutable ça, c'est la taille de la mémoire allouable à un processus

Heuu non ça n'impose pas de tout avoir en mémoire en permanence, et justement dans ton cas et vu les volumes de données ce serait plus que probablement une bonne idée de faire des recherches sur le chargement partiel et l'optimisation de la taille en mémoire

Masklinn:
 
Merci de ta rectification, je voulais bien parler de la taille de la memoire allouable a un processus !
 
En fait, si ces images super big ne sont pas en memoire ... elle seront sur le disque dur et charger 400 Mb aussi vite que possible a partir d'un disque dur, ca prend quand meme du temps (j'ai deja tenté la piste Raid  5 pour un gros throughput des données) et je divise mon temps de loading par 2.
 
Au final, je dois pouvoir loader
- toutes les images d'un patient en memoire le plus vite possible
- pendant que l'utilisateur regarde ces images et les manipule je loade les images du (ou des) patients suivants (present dans une "worklist" )
(idealement il serait interessant de bufferiser les 3 ou 4 patients suivants)
- au lieu de loader les images du patient suivant a partir du disque dur, je les loaderai directement a partir de la ram
 
Throughput HD = 65Mo seconde
Throughput Raid 5 = 166 Mo seconde (sur perc 5i / 4 disk de 750go)
Throughput Ram DDR2 = plusieurs Go/seconde
 
inconnu : debit max de la carte graphique (qui semble etre une bouse et je n'ai pas le droit de la changer, elle pilote des ecrans specifiques)

bjone:
si je suis limité par l'os qui dit:
4 Gb max utilisable en environnement 32bit (XP Pro 32 bit / 2003 Server 32 bit)
 
la solution sera en effet de passer a du 64 bit et la je pourrais utiliser si il le faut une config avec 6 ou 8 Gb de ram sans probleme (histoire de bufferiser sans probleme 10 a 12 patients en ram)
 

Bien sûr que ça prend plus de temps et que c'est plus lent.
 
Le truc, c'est qu'un logiciel rapide qui marche pas, il sert à rien. Un logiciel lent qui fonctionne par contre ça a un intérêt, et ça peut ensuite être accéléré

Masklinn:
 
en fait, j'ai deja un "work around" pour ne pas bloquer l'appli et il consiste a charger les images une par une dans le cas d'examens tres gros.
 
Par ailleurs, le probleme ne s'est presenté qu'une fois sur 3000 cas. La situation est de ce fait exeptionnelle.
 
Par contre, je prefere me dire que ce serait pas mal d'anticiper les problemes a venir ...
 
 
 

Ouf, de l'imagerie. Clairement il faut optimiser tes allocations mémoires. Je bosse un peu près dans un domaine similaire (imprimerie : je dois afficher des images à plusieurs plans assez gigantesques : TIFF 1bit G4 200000x150000px). Décompressé, ça fait plusieurs Go en RAM. Impossible à charger sur une machine 32bits.
 
Plusieurs solutions possibles, et autant te dire tout de suite qu'il y du boulot pour gérer ça correctement :
* Images pyramidales : c'est le truc classique que quasiment tous les logiciels de visualisations font pour des images gigantesques. Tu pré-process tes images pour en faire des fichier tuilés (le TIFF gère ça en natif) et tu généres plusieurs images à des résolutions de plus en plus petites jusqu'à obtenir un truc affichable à l'écran. C'est délicat à gérer : plusieurs fichiers à traiter en parallèle (donc multi-thread, sinon c'est trop lent), en C forcément (donc risque de tirage de balle dans les pieds). Inconvénient : pré-traitement à faire. Petit bench vite fait : 4 TIFF CMYK G4 200000x150000, disque SCSI dual Xeon 2.4Ghz, prétraité sur 2 niveaux : 1 minute 30 de processing (ça implique : décompresser les 4 fichiers g4, créer 4 fichiers tuilés (256x256px) équivalents recompressés en G4 et créer 4 autres fichiers tuilés 8bits en parallèle, à 1/8 de la résolution du g4, compressé en LZW). Fichiers originaux faisaient dans les 760Mo, ça a créer 1Go de fichier temporaires. Avantages : accès constant quel que soit le niveau de zoom et de l'endroit que tu visualises et ça ne consomme pas beaucoup de RAM (en mode IDLE mon appli prends moins de 10Mo, quand on charge des tuiles, ça peut monter à 100Mo).
 
* Fichiers mappé en mémoire : là il faut que tes données fasse moins de 2Go (décompressée, ou si tu es un vrai kador, tu peux tenter une décompression à la volée). Windows et Linux savent faire ça très bien, c'est très rapide (infiniment plus que faire du streaming "à la main" ). Le hic, c'est qu'il faut un fichier non compressé. Un fichier mappé en mémoire permet d'accéder au fichier comme s'il s'agissait d'une chaine de caractère. Le système d'exploitation va se démerder pour charger/libérer les pages en fonction de la partie du fichier accédée. Inconvénient : pas d'image de plus de 2Go et le premier accès va être super lent (le temps que les pages soient dans le cache disque).
 
Edit : L'autre avantage des fichiers mappés, c'est que ça ne va pas (trop) fragmenter la mémoire de ton processus, puisque les blocs alloués seront indépendants de ton heap. Et surtout lorsque tu supprime ton placage en RAM, le système va réellement libérer la RAM associé.
 
Je pense que c'est une solution que tu devrais explorer. La première sera trop de boulot si tu n'as pas prévu ça à l'origine.

Qques corrections.
 
Premièrement xp, en 32bits split par défaut l'espace d'adressage en 2G/2G (espace utilisateur/noyau); il est cependant possible de passer en 3/1 ou encore d'activer la PAE, tjs en restant en mode 32bits.
Mais il y a bataille pour caser dans ces 2G (par défaut) tout un assortiment de verrues; d'ou un morcellement; d'ou les problèmes à allouer un espace contigue. Les dlls sont à compter parmi ces verrues.
Une premiere approche est donc de prendre de vitesse tout le monde. Il est assez facile de réclamer 1.8G de cette façon.
 
Je passe sur le out-of-core (bien que le mappage y ait à voir), pour signaler que l'on peut mapper partiellement un fichier et, par exemple, coller des handler sur les page fault pour bouger la fenêtre (de façon transparente).
Même sur xp. Maintenant reste à savoir pourquoi diable on utiliserait xp pour ce genre de manip.

la solution ficheir mappé est la meilleur AMHA.
Me semble que tt les applis manipulant des blady big images utilisnt ça

Sauf que comparé à la simplicité biblique d'un mmap, win32/64 est une tannée. Et que la problématique de la fragmentation reste la même tant pour un VirtualAlloc que MapViewOfFile; c'est l'espace d'adressage qui fait défaut.

passe en 64bits

ah certes J'ai jamais mmappé sous win faut dire :s
 
en fait :
http://www.boost.org/libs/iostream [...] _file.html

moi j'essayerais de passer en 64 bits

Exactement. J'ai rencontré exactement le même problème sous Linux pour exactement la même application (imagerie médicale, images DICOM). La seule solution était effectivement le portage en 64 bits.

el muchacho:
 
tu bosses chez G E ? perso je connais que la Advantage Window qui tourne sous nux

Avec de très grosses images, il serait intéressant de tester avec le logiciel ImageVisu.