Discussion :

[Higgins]

Bonjour,
J'utilise des procédures stockées sur base de données SQL Server

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
var monObjet:TSQLStoredProc;
begin
   monObjet:=TSQLStroredProc.create(nil);
  with monObjet do
  begin
        SQLConnection:=maConnexion;       
        storedprocname:=maprocedure;
       open;
       //ici traitement des données lues
  end;
monObjet.close;
monObjet.free;
end;

En appelant ce bout de code dans une boucle, je me suis aperçu que la mémoire associée n'est pas vraiment libérée.
Après l'appel à monObjet.free, si je fais une vérification, la variable n'est pas à nil et à chaque boucle, la mémoire occupée par l'exécutable augmente de quelques centaines de Ko, jusqu'à provoquer une erreur "mémoire insuffisante"
J'ai essayé de mettre FreeAndNil(onObjet) à la place de monObjet.free, il passe bien à nil mais la mémoire n'est pas libérée.
Existe-t-il un moyen de "forcer" la libération de la mémoire?

J'ai essayé de remplacer la procédure stockée par un TSQLQuery et c'est mieux mais je ne peux pas remplacer toutes les procédures stockées.
Faut-il faire une action particulière après avoir utilisé une procédure stockée?

[SergioMaster]

bonjour,

Sans avoir tester , je pense que la TSQLStoredProc est préparée , suite à son open .
Que penserais tu d'un unPrepare avant de 'libérer' cette dernière ?
[Edit] unprepare n'existe bien sur pas avec DBExpress mais cleanupInstance oui

PS. Je préfére une structure try finally même si ton code fonctionne

[Higgins]

Merci pour l'info, mais cleanupinstance n'apporte rien.
Par contre, je suspecte la présence d'une sorte de "garbage collector" car lorsque je relance le traitement, les premiers enregistrements traités sont ignorés et ma boucle tourne "à vide".
Au bout d'un moment, l'empreinte mémoire qui était montée à 40mo suite à l'ouverture de plusieurs form, tombe à 3Mo pendant la boucle vide, avant de repartir à la hausse lorsque la procédure stockée est appelée

[Higgins]

Petit détail troublant, l'augmentation de la taille en mémoire est nettement moins "rapide" en mode debug dans rad studio sur mon W7 pro par rapport à l'exécutable autonome sur un Windows server 2008.

Est-ce que rad studio "nettoie" au fur et à mesure en mode debug, ou est-ce l'OS qui se comporte différemment?

[ShaiLeTroll]

Ou alors le mode debug est plus lent car monitoré par le RAD !
Et donc le nombre de cycle d'exécution est moins important

[Higgins]

Ou alors le mode debug est plus lent car monitoré par le RAD !
Et donc le nombre de cycle d'exécution est moins important

Je me suis mal exprimé en disant "moins rapide", je voulais dire en plus petite quantité à chaque itération.
exemple:
en mode debug, sur mon PC, l'appli occupe environ 80Mo avant le début du traitement puis monte progressivement jusqu'à environ 250Mo

Sur le serveur de production, l'appli démarre à 25Mo environ (eh oui, ça fait une sacré différence entre DEBUG et RELEASE)
Pendant le traitement, l'empreinte mémoire augmente rapidement, jusqu'à dépasser 800Mo et planter pour cause de ressources insuffisantes

[exoseven]

si ce n'est pas une fuite de mémoire (tu as essayé un ReportMemoryLeaksOnShutdown := True; ? ) mais si le problème est du à une trop grande fragmentation du peux essayer un code du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
procedure TrimAppMemorySize;
 var
   MainHandle : THandle;
 begin
   try
     MainHandle := OpenProcess(PROCESS_ALL_ACCESS, false, GetCurrentProcessID) ;
     SetProcessWorkingSetSize(MainHandle, $FFFFFFFF, $FFFFFFFF) ;
     CloseHandle(MainHandle) ;
   except
   end;
   Application.ProcessMessages;
 end;

c'est pas très propre mais cela va libérer de la mémoire, comme quand tu minimises ton application, bien sur ta mémoire remonte après donc il faut le faire de temps en temps

voir ce sujet qui ressemble à ton problème

tu peux aussi envisager de ne pas créer/libérer une multitude de fois tes objets mais de les réutiliser cela évitera une trop grande fragmentation

[Higgins]

c'est pas très propre mais cela va libérer de la mémoire, comme quand tu minimises ton application, bien sur ta mémoire remonte après donc il faut le faire de temps en temps

ça fonctionne nickel !

Le fond du problème est certainement une fuite de mémoire mais même avec FastMM, je n'ai pas trouvé où elle se trouve.
En attendant, je peux faire tourner l'appli sans saturer la mémoire.
Encore merci !