Discussion :

[__JP__]

Bonjour à tous,

Je viens de rencontrer un problème avec l'utilisation de la mémoire par le FrameWork .Net 2.0

Je n'arrive pas à dépasser 1680 Mo avec une application .Net
(Ne me demandez pas si je peux réduire l'utilisation de cette mémoire, cela m'est impossible).

Je me pose plusieurs questions :

Y a t il un moyen pour spécifier la quantité maximum de mémoire utilisé par une application dotnet (option du compilateur, option du framework)

Est ce que la limite vient plutot du garbage collector?, est il possible de l'augmenter ?



Pour info :
Test effectue sur plusieurs machine
1# 4go de ram (500 Mo d'utilisé avant lancement de mon application)
2# 1Go de ram (1,4 Go utilisé avant lancement de l'application, autrement dit mon application s'est tout de suite mise à swapper (le mémoire virtuelle est de 4Go sur cette machine))

Dans les deux cas , une fois la limite de 1680 Mo atteinte par l'application, une exception OutOfMemory est levée.


Merci d'avance pour vos réponses.

[Keihilin]

Je ne suis pas sûr qu'il s'agisse d'une limitation propre à .Net mais plutôt au process sur un OS 32 bits...
Maintenant, à cause justement de la limitation sur le process, il est possible que la CLR impose elle aussi cette limitation.

As-tu essayé de placer un switch /3GB dans boot.ini ?

Tu travailles sur de l'imagerie médicale ou quelque chose du genre ?

[neptune]

Je n'ai pas la réponse à ton problème, mais un lien assez intéressant, lu ce matin sur le sujet.

Raymond Chen notes that if you have to ask where the operating system limits are, you're probably doing something wrong...

http://www.codinghorror.com/blog/archives/000966.html

[Keihilin]

Je n'ai pas la réponse à ton problème, mais un lien assez intéressant, lu ce matin sur le sujet.
http://www.codinghorror.com/blog/archives/000966.html

C'est effectivemet intéressant, mais les limitations de mémoire peuvent être problématiques dans certains domaines d'imagerie (médicale, astronomique) sans forcément qu'un mauvais design soit en cause...

[neptune]

C'est effectivemet intéressant, mais les limitations de mémoire peuvent être problématiques dans certains domaines d'imagerie (médicale, astronomique) sans forcément qu'un mauvais design soit en cause...

Oui, j'y pensais en lisant ton premier post sur ce thread, mais le choix de l'OS fait partie du design...

[__JP__]

Merci à tous pour vos réponses si rapide.
Voila les miennes...

As-tu essayé de placer un switch /3GB dans boot.ini ?

Oui, le boot.ini à été modifié sur la machine N°1 mais pas sur la machine N°2, cependant aucune différence. (C'est pour cela que je penchais vers une limitation du Framework)

Raymond Chen notes that if you have to ask where the operating system limits are, you're probably doing something wrong...

Je suis tout a fait d'accord avec ca. Malheureusement je n'ai pas le droit de modifier le code de mon application, car je la fais développer par une société externe. De plus j'ai besoin d'une solution rapidement, je ne peux pas attendre que mon prestataires revoie son algorithme.

Merci de votre aide, mais j'ai l'impression qu'il ne sera pas possible de résoudre mon problème sans revoir l'algorithme posant problème.
Mais tout de même, une limitation de 1,6Go, ca ne vous parait pas ridicule. Aujourd'hui beaucoup d'application ont besoin de plusieurs Go de mémoire pour fonctionner. Le FrameWork .Net n'est peut être pas destiné à développer des application complexe et gourmande...

[Keihilin]

Oui, le boot.ini à été modifié sur la machine N°1 mais pas sur la machine N°2, cependant aucune différence. (C'est pour cela que je penchais vers une limitation du Framework)

C'est un bon début, mais il faut également que l'application sache qu'elle peut utiliser plus de mémoire.

Il faut faire un LINK avec l'option LARGEADDRESSAWARE

--> editbin /LARGEADDRESSAWARE myApp.exe

Je suis tout a fait d'accord avec ca. Malheureusement je n'ai pas le droit de modifier le code de mon application, car je la fais développer par une société externe. De plus j'ai besoin d'une solution rapidement, je ne peux pas attendre que mon prestataires revoie son algorithme.

Je ne suis pas sûr du sens de ta phrase, mais si tu es le mandant d'un développement, le code source de l'application t'appartient, sauf mention spécifique. D'autre part, la société qui développe à la responsabilité de livrer quelque chose qui fonctionne et de ne pas confier un développement visiblement important à des juniors qui ont commencé .NET avant-hier.

Merci de votre aide, mais j'ai l'impression qu'il ne sera pas possible de résoudre mon problème sans revoir l'algorithme posant problème.
Mais tout de même, une limitation de 1,6Go, ca ne vous parait pas ridicule. Aujourd'hui beaucoup d'application ont besoin de plusieurs Go de mémoire pour fonctionner. Le FrameWork .Net n'est peut être pas destiné à développer des application complexe et gourmande...

Non, il n'y a pas beaucoup d'applications qui explosent les limitations de l'OS, ce sont des problématiques limitées à certains domaines et .NET n'est que partiellement "responsable" de ces difficultés; les limitations sont au niveau de l'OS même et l'on touche à des questions matérielles.
La difficulté ajouté par .NET dans ce cas est que la CLR va vouloir un bloc de mémoire continu, et ça, même avec 4Go de RAM et l'option /3Gb, rien ne garantie qu'elle pourra l'avoir.

Cela dit, c'est une chose à laquelle il aurait fallut penser au moment des specs...

Tu ne nous a pas dit dans quel domaine tu utilises cette application ?

[__JP__]

Il faut faire un LINK avec l'option LARGEADDRESSAWARE

--> editbin /LARGEADDRESSAWARE myApp.exe

Merci pour l'info, je ne connaissais pas cela, je vais essayer.

Je ne suis pas sûr du sens de ta phrase, mais si tu es le mandant d'un développement, le code source de l'application t'appartient, sauf mention spécifique. D'autre part, la société qui développe à la responsabilité de livrer quelque chose qui fonctionne et de ne pas confier un développement visiblement important à des juniors qui ont commencé .NET avant-hier.

Je suis propriétaire des sources, mais le contrat de maintenance que j'ai avec mon prestataire m'en interdit la modification.

Tu ne nous a pas dit dans quel domaine tu utilises cette application ?

C'est un logiciel de gestion opérationnelle, comptable, facturation avec plusieurs centaines d'utilisateurs en simultané

Le problème se situe dans un processus de facturation permettant la génération d'un rapport en fonction d'écriture comptable (Plusieurs millions dans le cas qui provoque le plantage)

[Keihilin]

Le problème se situe dans un processus de facturation permettant la génération d'un rapport en fonction d'écriture comptable (Plusieurs millions dans le cas qui provoque le plantage)

des Go de mémoire utilisés pour quelques millions d'écritures comptables ???

Alors là, d'instinct je peux te l'affirmer : MAUVAIS DESIGN, MAUVAIS ALGORYTHME.

[__JP__]

Je reviens vers vous après mes différents tests

--> editbin /LARGEADDRESSAWARE myApp.exe

Aucune différence, d'ailleurs après avoir parcouru divers sites, il semblerait que cela soit plutôt destiné à des applications conçu pour un environnement 64 bits

J'ai aussi essayé de modifier le paramètre memorylimit du fichier machine.config du Framework, mais sans plus de résultat.

Apparemment le FrameWork .Net peut gérer beaucoup plus de mémoire sur un environnement 64 bits (logique me direz vous, car les possibilité d'adressage sont plus entendues sur ce type de système)

Une solution serai peut être de faire tourner mon programme sur une machine 64 bits. La question que je me pose : Est ce que le passage en 64 bits necessite des modifications dans le code de mon application (Autre que des optmisations pour un système 64 bits "falcutative"), le passage de la compilation sur un système 32 bits à un système 64 bits est il transparent ?

Merci d'avance pour vos réponses

[Keihilin]

avant de te lancer dans une migration sur du 64 bits, tu devrais peut être envisager un peu de refactoring...

Est-ce que tu peux nous montrer ton code ou pas ?

[__JP__]

des Go de mémoire utilisés pour quelques millions d'écritures comptables ???

Alors là, d'instinct je peux te l'affirmer : MAUVAIS DESIGN, MAUVAIS ALGORYTHME.

Je suis tout à fait d'accord avec toi. Moi même je ne connais pas le fonctionnement de cet algorithme (je n'en ai pas fait les specs, je ne les ai d'ailleurs pas dans l'immédiat), mais il est évidant que son fonctionnement n'a pas été suffisamment optimisé.

[__JP__]

avant de te lancer dans une migration sur du 64 bits...

Dois je en déduire que le passage au 64 bits serait laborieux ?

Est-ce que tu peux nous montrer ton code ou pas ?

Malheureusement non, pour des raisons contractuelle.

Note :Je tiens à préciser que je ne connais pas du tout le code de cet algorithme, (je peux y accéder (pas dans l'immédiat), mais je n'ai pas eu le temps de le regarder, j'ai surtout essayé de trouver une solution en urgence)

[Keihilin]

Dois je en déduire que le passage au 64 bits serait laborieux ?

Laborieux non, mais il est loin d'être sûr que cela résolve ton problème...

Malheureusement non, pour des raisons contractuelle.

Il m'a l'air bien velu ton contrat...C'est sans doute de la paranoïa due à mon expérience, mais ça me paraît drôlement obscur tout ça.

[__JP__]

Il m'a l'air bien velu ton contrat...C'est sans doute de la paranoïa due à mon expérience, mais ça me parait drôlement obscur tout ça.

C'est un contrat de maintenance assez banale en fait.

Je pourrais tout à fait modifier l'algorithme. Mais je devrais ensuite soumettre mes modifications à mon prestataire pour acceptation dans le code couvert par mon contrat de maintenance. (sachant que le faire me coutera du temps, sans parler du temps nécessaire à sa compréhension, puis de l'argent perdu ,car le temps de contrôle nécessaire à mon prestataire sera une prestation hors contrat).

J'ai plutôt intérêt à laisser mon prestataire corriger cet algo, car ceci est couvert par mon contrat de maintenance.

Comme je le disais, j'ai surtout essayé de trouver une solution en urgence (le problème étant apparut cet après midi). Mais là, on s'écarte un peu du sujet de départ

Je penses que l'on peut clore cette discussion. L'algorithme sera probablement corrigé rapidement (enfin je l'espère ;( ).


Merci de ton aide Keihilin.