par la commande suivante " select * from master..sysprocesses orderby by
memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire
en SQL.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est
libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire
au fur et à mesure et ne la libère jamais.
Avez-vous une idée quant à l'origine de ce phénomène ?
L'application a été écrite en VB6 Service Pack 5.
Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL.
Il s'agit d'un service SQL 2000 SP4 Enterprise Edition
L'OS est un Windows 2003 SP1.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Bonjour,
Robert a écrit :
par la commande suivante " select * from master..sysprocesses orderby by memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire en SQL.
Rien de plus normal.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire au fur et à mesure et ne la libère jamais.
C'est encore une fois tout à fait normal. C'est le comportement par défaut de SQL Server, comme de tout serveur de bases de données relationnelles.
Avez-vous une idée quant à l'origine de ce phénomène ?
Oui ! Il suffit de vous expliquer comment fonctionne un SGBDR C/S ...
Chaque fois qu'une donnée est demandée, celle-ci est copié du disque en RAM, car il y a fort à parier qu'elle sera redemandée. Cela s'apelle de la mise en cache. Tant que la mémoire n'est pas entièrement consommée, SQL Server continu de mettre en cache. Si le cache commence à saturer, alors SQL Server remplace les pages les plus anciennes par les nouvelles demandées (algorithme LRU : Last recent Use).
Même les mises à jour se font en cache.
Si le SGBDR devait lire les données depuis le disque à chaque transaction (SELECT, INSERT, UPDATE, DELETE....) vous auriez des temps de réponse catastrophique et il vaudrait mieux développer votre application en fichier COBOL ! Entre un accès disque (temps de réponse d'environ 10 ms) et un accès mémoire (10 nano seconde) il existe un rapport de 1 à 1000000 (un million). En pratique on compte un rapport de 1 à 1000... C'est pourquoi la mise en cache est indispensable et plus la fenêtre des données exploitées est importante plus la RAM doit être importante !
L'application a été écrite en VB6 Service Pack 5. Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL. Il s'agit d'un service SQL 2000 SP4 Enterprise Edition L'OS est un Windows 2003 SP1.
Votre application n'est pas en cause !
D'avance, merci.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Bonjour,
Robert a écrit :
par la commande suivante " select * from master..sysprocesses orderby by
memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire
en SQL.
Rien de plus normal.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est
libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire
au fur et à mesure et ne la libère jamais.
C'est encore une fois tout à fait normal. C'est le comportement par
défaut de SQL Server, comme de tout serveur de bases de données
relationnelles.
Avez-vous une idée quant à l'origine de ce phénomène ?
Oui !
Il suffit de vous expliquer comment fonctionne un SGBDR C/S ...
Chaque fois qu'une donnée est demandée, celle-ci est copié du disque en
RAM, car il y a fort à parier qu'elle sera redemandée. Cela s'apelle de
la mise en cache. Tant que la mémoire n'est pas entièrement consommée,
SQL Server continu de mettre en cache. Si le cache commence à saturer,
alors SQL Server remplace les pages les plus anciennes par les nouvelles
demandées (algorithme LRU : Last recent Use).
Même les mises à jour se font en cache.
Si le SGBDR devait lire les données depuis le disque à chaque
transaction (SELECT, INSERT, UPDATE, DELETE....) vous auriez des temps
de réponse catastrophique et il vaudrait mieux développer votre
application en fichier COBOL !
Entre un accès disque (temps de réponse d'environ 10 ms) et un accès
mémoire (10 nano seconde) il existe un rapport de 1 à 1000000 (un
million). En pratique on compte un rapport de 1 à 1000...
C'est pourquoi la mise en cache est indispensable et plus la fenêtre des
données exploitées est importante plus la RAM doit être importante !
L'application a été écrite en VB6 Service Pack 5.
Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL.
Il s'agit d'un service SQL 2000 SP4 Enterprise Edition
L'OS est un Windows 2003 SP1.
Votre application n'est pas en cause !
D'avance, merci.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
par la commande suivante " select * from master..sysprocesses orderby by memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire en SQL.
Rien de plus normal.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire au fur et à mesure et ne la libère jamais.
C'est encore une fois tout à fait normal. C'est le comportement par défaut de SQL Server, comme de tout serveur de bases de données relationnelles.
Avez-vous une idée quant à l'origine de ce phénomène ?
Oui ! Il suffit de vous expliquer comment fonctionne un SGBDR C/S ...
Chaque fois qu'une donnée est demandée, celle-ci est copié du disque en RAM, car il y a fort à parier qu'elle sera redemandée. Cela s'apelle de la mise en cache. Tant que la mémoire n'est pas entièrement consommée, SQL Server continu de mettre en cache. Si le cache commence à saturer, alors SQL Server remplace les pages les plus anciennes par les nouvelles demandées (algorithme LRU : Last recent Use).
Même les mises à jour se font en cache.
Si le SGBDR devait lire les données depuis le disque à chaque transaction (SELECT, INSERT, UPDATE, DELETE....) vous auriez des temps de réponse catastrophique et il vaudrait mieux développer votre application en fichier COBOL ! Entre un accès disque (temps de réponse d'environ 10 ms) et un accès mémoire (10 nano seconde) il existe un rapport de 1 à 1000000 (un million). En pratique on compte un rapport de 1 à 1000... C'est pourquoi la mise en cache est indispensable et plus la fenêtre des données exploitées est importante plus la RAM doit être importante !
L'application a été écrite en VB6 Service Pack 5. Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL. Il s'agit d'un service SQL 2000 SP4 Enterprise Edition L'OS est un Windows 2003 SP1.
Votre application n'est pas en cause !
D'avance, merci.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Robert
Merci.
Toutefois, je pense que j'ai mal expliqué le phénomène que je décris.
Votre réponse concerne l'occupation mémoire d'un service SQL. Je comprends très bien qu'un service SQL consomme toute la mémoire disponible. C'est d'ailleurs la raison pour laquelle on a installé 8 GB de RAM. On a justement configuré le serveur pour qu'un processus puisse aller au delà de la limite des 2 GB (option /3GB dans le boot.ini) et configuré la mémoire AWE.
On a réservé ainsi 7 GB pour le service SQL, qu'il occupe en totalité, et 1 GB pour l'OS, et ce pour améliorer les opérations de lectures/écritures.
Toutefois, ma question concerne la mémoire allouée à un processus exécuté par le service SQL dans le cache SQL.
Lorsque j'exécute SELECT * FROM master..SYSPROCESSES, j'obtiens tous les processus exécuté par le service SQL. Or, c'est sur l'occupation mémoire des processus exécutés par le service SQL qui me préoccupe.
Nous avons beaucoup d’applications qui accèdent au serveur SQL, Or une de ces applications utilise 2,7 GB de cache SQL tandis que les autres utilise quelques mégas tout au plus. Pourquoi ?
D'avance, merci.
Merci.
Toutefois, je pense que j'ai mal expliqué le phénomène que je décris.
Votre réponse concerne l'occupation mémoire d'un service SQL. Je comprends
très bien qu'un service SQL consomme toute la mémoire disponible. C'est
d'ailleurs la raison pour laquelle on a installé 8 GB de RAM. On a justement
configuré le serveur pour qu'un processus puisse aller au delà de la limite
des 2 GB (option /3GB dans le boot.ini) et configuré la mémoire AWE.
On a réservé ainsi 7 GB pour le service SQL, qu'il occupe en totalité, et 1
GB pour l'OS, et ce pour améliorer les opérations de lectures/écritures.
Toutefois, ma question concerne la mémoire allouée à un processus exécuté
par le service SQL dans le cache SQL.
Lorsque j'exécute SELECT * FROM master..SYSPROCESSES, j'obtiens tous les
processus exécuté par le service SQL. Or, c'est sur l'occupation mémoire des
processus exécutés par le service SQL qui me préoccupe.
Nous avons beaucoup d’applications qui accèdent au serveur SQL, Or une de
ces applications utilise 2,7 GB de cache SQL tandis que les autres utilise
quelques mégas tout au plus. Pourquoi ?
Toutefois, je pense que j'ai mal expliqué le phénomène que je décris.
Votre réponse concerne l'occupation mémoire d'un service SQL. Je comprends très bien qu'un service SQL consomme toute la mémoire disponible. C'est d'ailleurs la raison pour laquelle on a installé 8 GB de RAM. On a justement configuré le serveur pour qu'un processus puisse aller au delà de la limite des 2 GB (option /3GB dans le boot.ini) et configuré la mémoire AWE.
On a réservé ainsi 7 GB pour le service SQL, qu'il occupe en totalité, et 1 GB pour l'OS, et ce pour améliorer les opérations de lectures/écritures.
Toutefois, ma question concerne la mémoire allouée à un processus exécuté par le service SQL dans le cache SQL.
Lorsque j'exécute SELECT * FROM master..SYSPROCESSES, j'obtiens tous les processus exécuté par le service SQL. Or, c'est sur l'occupation mémoire des processus exécutés par le service SQL qui me préoccupe.
Nous avons beaucoup d’applications qui accèdent au serveur SQL, Or une de ces applications utilise 2,7 GB de cache SQL tandis que les autres utilise quelques mégas tout au plus. Pourquoi ?
D'avance, merci.
Med Bouchenafa
En dehors du fait que la mémoire AWE est gérée de manière particuliére, je dirais que tant que le process est actif, il conserve la mémoire qui lui a été allouée Ce n'est peut-être pas le cas et tu demandes pourquoi la mémoire reste occupée. En fait comment tu fais pour dire que ton process n'est plus actif Je ne me souviens plus vraiment des détails mais je sais que AWE n'est pas libérée systmatiquement Il faut que je retrouve mes documents sur le sujet. Lionel de Microsoft France avait organisé une conférence sur le sujet.
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
par la commande suivante " select * from master..sysprocesses orderby by memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire en SQL.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire au fur et à mesure et ne la libère jamais.
Avez-vous une idée quant à l'origine de ce phénomène ?
L'application a été écrite en VB6 Service Pack 5. Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL. Il s'agit d'un service SQL 2000 SP4 Enterprise Edition L'OS est un Windows 2003 SP1.
D'avance, merci.
En dehors du fait que la mémoire AWE est gérée de manière particuliére, je
dirais que tant que le process est actif, il conserve la mémoire qui lui a
été allouée
Ce n'est peut-être pas le cas et tu demandes pourquoi la mémoire reste
occupée.
En fait comment tu fais pour dire que ton process n'est plus actif
Je ne me souviens plus vraiment des détails mais je sais que AWE n'est pas
libérée systmatiquement
Il faut que je retrouve mes documents sur le sujet.
Lionel de Microsoft France avait organisé une conférence sur le sujet.
--
Bien cordialement
Med Bouchenafa
"Robert" <Robert@discussions.microsoft.com> wrote in message
news:01D474FA-F4CA-4B4A-BE3C-7CACE8E6BED5@microsoft.com...
par la commande suivante " select * from master..sysprocesses orderby by
memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de
mémoire
en SQL.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est
libérée, mais ce processus, lorsqu'il est redémarré, accapare de la
mémoire
au fur et à mesure et ne la libère jamais.
Avez-vous une idée quant à l'origine de ce phénomène ?
L'application a été écrite en VB6 Service Pack 5.
Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL.
Il s'agit d'un service SQL 2000 SP4 Enterprise Edition
L'OS est un Windows 2003 SP1.
En dehors du fait que la mémoire AWE est gérée de manière particuliére, je dirais que tant que le process est actif, il conserve la mémoire qui lui a été allouée Ce n'est peut-être pas le cas et tu demandes pourquoi la mémoire reste occupée. En fait comment tu fais pour dire que ton process n'est plus actif Je ne me souviens plus vraiment des détails mais je sais que AWE n'est pas libérée systmatiquement Il faut que je retrouve mes documents sur le sujet. Lionel de Microsoft France avait organisé une conférence sur le sujet.
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
par la commande suivante " select * from master..sysprocesses orderby by memusage desc", j'ai remarqué qu'une application occupait 2,7 GB de mémoire en SQL.
Lorsque l'on arrête ce processus et qu'on le redémarre, la mémoire est libérée, mais ce processus, lorsqu'il est redémarré, accapare de la mémoire au fur et à mesure et ne la libère jamais.
Avez-vous une idée quant à l'origine de ce phénomène ?
L'application a été écrite en VB6 Service Pack 5. Le serveur SQL dispose de 8 GB, dont 7 GB alloué au service SQL. Il s'agit d'un service SQL 2000 SP4 Enterprise Edition L'OS est un Windows 2003 SP1.
D'avance, merci.
Robert
L'application en question tourne en permanence mais est arretée quelques minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire est consommée petit a petit jusqu'à atteindre 2,7 GB.
L'application en question tourne en permanence mais est arretée quelques
minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire est
consommée petit a petit jusqu'à atteindre 2,7 GB.
L'application en question tourne en permanence mais est arretée quelques minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire est consommée petit a petit jusqu'à atteindre 2,7 GB.
Med Bouchenafa
Je crois aussi me souvenir que les colonnes de sysprocesses sont cuéulatives ce qui expliquerait pourquoi le comportement que tu signales Mais je conviens que cela n'explique pas pourquoi la valeur se stabilise à 2.7 Go
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
L'application en question tourne en permanence mais est arretée quelques minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire est consommée petit a petit jusqu'à atteindre 2,7 GB.
Je crois aussi me souvenir que les colonnes de sysprocesses sont cuéulatives
ce qui expliquerait pourquoi le comportement que tu signales
Mais je conviens que cela n'explique pas pourquoi la valeur se stabilise à
2.7 Go
--
Bien cordialement
Med Bouchenafa
"Robert" <Robert@discussions.microsoft.com> wrote in message
news:6099B295-2ED7-40CA-9586-148DC2291B06@microsoft.com...
L'application en question tourne en permanence mais est arretée quelques
minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire
est
consommée petit a petit jusqu'à atteindre 2,7 GB.
Je crois aussi me souvenir que les colonnes de sysprocesses sont cuéulatives ce qui expliquerait pourquoi le comportement que tu signales Mais je conviens que cela n'explique pas pourquoi la valeur se stabilise à 2.7 Go
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
L'application en question tourne en permanence mais est arretée quelques minutes chaque dimanche. Depuis le redémarrage du processus, la mémoire est consommée petit a petit jusqu'à atteindre 2,7 GB.
Robert
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche
(j'avais oublié de le précisé).
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
Fred BROUARD
Robert a écrit :
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
la valeur de 2,7 Gb est la limite de ce que peut prendre directement SQL Server.
En effet dans votre config vous avez 8 Go de RAM. Mais en fait un proc 32 bits ne peut pas adresser plus de 4 Go de RAM. A aucun moment il n'y aura accès direct à une adresse supérieure à 4 Go. Hors dans votre config vous indiquez avoir mis 1 Go à dispo de l'OS. Il n'y a plus donc que 3 Go disponible pour toutes les autres applications. 3 Go - 2,7 Go = 300 Mo. Ces 300 Mo sont affectés à d'autres processus que SQL Server (d'autres services). Le processus dont vous parlez et qui consomme ces 2,7 Go est en fait SQL Server lui même, c'est à dire l'ensemble de la gestion des caches.
Mais à quoi servent les 4 Go supérieur alors ??? Ils servent en fait à la pagination. Plutôt que de paginer en disque (pagefile.sys) lorsque vous activez AWE vous reportez la pagination disque en RAM haute, c'est à dire dans l'espace que le proc ne peut pas adresser, en fait tout ce qui est supérieur à 4 Go. Dans votre cas 4 Go de pagination.
Voila pour les explications. Si vous en voulez d'autres, venez au cours d'optimisation que j'ai mis au point pour Orsys ! http://www.orsys.fr/pdfCours/SQO.pdf
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Robert a écrit :
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche
(j'avais oublié de le précisé).
la valeur de 2,7 Gb est la limite de ce que peut prendre directement SQL
Server.
En effet dans votre config vous avez 8 Go de RAM. Mais en fait un proc
32 bits ne peut pas adresser plus de 4 Go de RAM. A aucun moment il n'y
aura accès direct à une adresse supérieure à 4 Go.
Hors dans votre config vous indiquez avoir mis 1 Go à dispo de l'OS.
Il n'y a plus donc que 3 Go disponible pour toutes les autres
applications. 3 Go - 2,7 Go = 300 Mo. Ces 300 Mo sont affectés à
d'autres processus que SQL Server (d'autres services).
Le processus dont vous parlez et qui consomme ces 2,7 Go est en fait SQL
Server lui même, c'est à dire l'ensemble de la gestion des caches.
Mais à quoi servent les 4 Go supérieur alors ???
Ils servent en fait à la pagination.
Plutôt que de paginer en disque (pagefile.sys) lorsque vous activez AWE
vous reportez la pagination disque en RAM haute, c'est à dire dans
l'espace que le proc ne peut pas adresser, en fait tout ce qui est
supérieur à 4 Go. Dans votre cas 4 Go de pagination.
Voila pour les explications.
Si vous en voulez d'autres, venez au cours d'optimisation que j'ai mis
au point pour Orsys !
http://www.orsys.fr/pdfCours/SQO.pdf
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
la valeur de 2,7 Gb est la limite de ce que peut prendre directement SQL Server.
En effet dans votre config vous avez 8 Go de RAM. Mais en fait un proc 32 bits ne peut pas adresser plus de 4 Go de RAM. A aucun moment il n'y aura accès direct à une adresse supérieure à 4 Go. Hors dans votre config vous indiquez avoir mis 1 Go à dispo de l'OS. Il n'y a plus donc que 3 Go disponible pour toutes les autres applications. 3 Go - 2,7 Go = 300 Mo. Ces 300 Mo sont affectés à d'autres processus que SQL Server (d'autres services). Le processus dont vous parlez et qui consomme ces 2,7 Go est en fait SQL Server lui même, c'est à dire l'ensemble de la gestion des caches.
Mais à quoi servent les 4 Go supérieur alors ??? Ils servent en fait à la pagination. Plutôt que de paginer en disque (pagefile.sys) lorsque vous activez AWE vous reportez la pagination disque en RAM haute, c'est à dire dans l'espace que le proc ne peut pas adresser, en fait tout ce qui est supérieur à 4 Go. Dans votre cas 4 Go de pagination.
Voila pour les explications. Si vous en voulez d'autres, venez au cours d'optimisation que j'ai mis au point pour Orsys ! http://www.orsys.fr/pdfCours/SQO.pdf
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Med Bouchenafa
Je viens de vérifier dans la documentation de SQL Server. Celle de 2005 est plus claire à ce sujet que celle de 2000 http://msdn2.microsoft.com/en-us/library/ms179881.aspx La colonne memusage n'est pas cumulative contrairement à d'autres colonnes de cette même table
Si le process fait toujours la même chose, il est effectivement curieux qu'il consomme de plus en plus de mémoire Tu es peut-être dans une situation de fuite mémoire Je pense qu'il faut soumettre le problème au support Microsoft qui ont peut-être d'autres moyens d'investiguer le probléme
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
Je viens de vérifier dans la documentation de SQL Server.
Celle de 2005 est plus claire à ce sujet que celle de 2000
http://msdn2.microsoft.com/en-us/library/ms179881.aspx
La colonne memusage n'est pas cumulative contrairement à d'autres colonnes
de cette même table
Si le process fait toujours la même chose, il est effectivement curieux
qu'il consomme de plus en plus de mémoire
Tu es peut-être dans une situation de fuite mémoire
Je pense qu'il faut soumettre le problème au support Microsoft qui ont
peut-être d'autres moyens d'investiguer le probléme
--
Bien cordialement
Med Bouchenafa
"Robert" <Robert@discussions.microsoft.com> wrote in message
news:B8228AAC-1491-4D63-91BF-756099EA4E5A@microsoft.com...
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche
(j'avais oublié de le précisé).
Je viens de vérifier dans la documentation de SQL Server. Celle de 2005 est plus claire à ce sujet que celle de 2000 http://msdn2.microsoft.com/en-us/library/ms179881.aspx La colonne memusage n'est pas cumulative contrairement à d'autres colonnes de cette même table
Si le process fait toujours la même chose, il est effectivement curieux qu'il consomme de plus en plus de mémoire Tu es peut-être dans une situation de fuite mémoire Je pense qu'il faut soumettre le problème au support Microsoft qui ont peut-être d'autres moyens d'investiguer le probléme
-- Bien cordialement Med Bouchenafa
"Robert" wrote in message news:
Les 2,7 GB est la valeur atteinte avant l'arrêt du process le dimanche (j'avais oublié de le précisé).
