mémoire insuffisante

Xgt <xgt@ifrance.com>, le mar. 05 août 2003 07:31:27, écrivait ceci:

bonjour

Salut,

MinFileCache@96
MaxFileCache 480
ChunkSizeQ2

C'est le réglage du fonctionnement de ta mémoire cache. Le plus simple AMHA
est d'utiliser Cacheman qui paramètre automatiquement en fonction de
l'utilisation que tu veux en faire.

ConservativeSwapfileUsage=0

C'est un gestionnaire de mémoire d'échange. J'en profite pour citer un
article de maitre JCB :
<copy on>

ConservativeSwapFileUsage=1,

Ouah la la!!!!!
Il y en a qui prennent leurs désirs pour des réalités!!! ;+)

Le paramètre "ConservativeSwapFileUsage" ne sert ABSOLUMENT PAS à se passer
de swap!

Tu devrais méditer sérieusement sur l'article Q223294 du MSDN pour te
rendre
compte que tu viens de dire une conceté (ou a minima que tu t'es exprimé
comme une pantoufle!;+) !
(mais ça arrive à tout le monde de dire des concetés ;+))

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q223294
"INFO: The Windows 98 PageFile_Call_Async_Manager Service"

En voici un aperçu (traduction rapide et personnelle!)
ATTENTION : les personnes sensibles et émotives devront s'abstenir de lire
ce qui suit!
(particulièrement indigeste!)

"Windows 98 a été doté d'une nouvelle fonctionnalité,
"PageFile_Call_Async_Manager", qui permet au
gestionnaire de mémoire d'écrire de façon asynchrone
dans le fichier de pagination durant les périodes
d'inactivité du système de fichiers VFAT.

Cette fonctionnalité peut affecter le comportement
des drivers virtuels (VxD) qui surveillent et/ou
interceptent les fonctions du driver VxD de
pagination.

L'article qui suit vous concerne si le VxD intercepte
de façon incomplète les lectures et écriture dans le
fichier de pagination sous Windows 98.

Vous pouvez désactiver cette fonctionnalité, qui peut
dégrader les performances du système au point de les
ramener à celles de Windows 95.

Il faut ajouter l'entrée suivante dans le fichier
"System.ini", section "[386Enh]":

[386Enh]
ConservativeSwapfileUsage=1

Si cette entrée vaut 1 comme ci-dessus,
PageFile_Call_Async_Manager n'est JAMAIS appelé.
Si cette entrée est absente dans System.ini,
par défaut le paramètre "ConservativeSwapfileUsage"
vaut
1 sous Windows 95,
0 (zéro) sous Windows 98.

Note JCB : cela veut dire que sous Win98, par DÉFAUT,
"PageFile_Call_Async_Manager" est TOUJOURS APPELÉ.

Lorsque Windows 98 effectue des écritures
asynchrones dans le fichier de swap, cette
activité n'est pas interceptée par la fonction
"PageFile_Read_Or_Write()".

Le service "PageFile_Set_Async_Manager" est
appelé par VFAT pour notifier que VFAT est
le gestionnaire d'activité asynchrone du swap.

En fait, cela a pour conséquence que le service
"PageFile_Call_Async_Manager" passe sous contrôle
d'un processus à l'intérieur même de VFAT.

Le gestionnaire de mémoire appelle
"PageFile_Call_Async_Manager", en transmettant
au service un pointeur vers un processus d'attente
"mmFsIdle" du système de fichiers (dans le
gestionnaire de mémoire).
Plus tard, VFAT appelle cette fonction lors de
ses périodes d'inactivités (toutes les écritures
en attente ont été réalisées), si bien que le
gestionnaire de mémoire peut effectuer des
écritures asynchrones :
ULONG INTERNAL mmFsIdle(void);
En retour, "PageFile_Call_Async_Manager" retourne
un pointeur vers une fonction utilisée par le
gestionnaire de mémoire pour écrire de façon
asynchrone dans le fichier de pagination :
extern int (CDECL *pfnAsyncPageOut)
(PVOID pvBuffer, ULONG bFileOffset);

Cette fonction réside en réalité dans VFAT
(WriteAsyncSwapPage), qui recopie une page
dans le tampon de cache et l'écrit.
"mmFsIdle" utilise un algorithme qui génère
des appels "pfnAsyncPageOut" (en réalité
des appels vers une routine interne de VFAT)

Ce qui suit montre comment le gestionnaire
de mémoire s'enregistre lui-même dans VFAT :
; le "callback" d'attente.
mov eax, offset32 _mmFsIdle@0
; NOTE: le gestionnaire est VFAT.
VxDCall PageFile_Call_Async_Manager ;
; échec
jc DICDoneP
; succès
mov _pfnAsyncPageOut, eax

En résumé "agricole JCB" :
--------------------------
On peut classer les écritures sur disque en 2 catégories :
- les écritures de "vrais" fichiers
(documents, BDR, ficheirs de config, journaux,..)
- les écritures dans le fichier de pagination (swap)

Dans Windows 98, Microsoft a voulu ajouter une "glute" qui est censée
améliorer les performances, en permettant une écriture asynchrone dans le
fichier de swap (2ème catégorie), en mettant à profit les périodes pendant
lesquelles le système de fichiers (VFAT) "glande" lamentablement (1ère
catégorie).

MAIS Microsoft s'est un peu planté, car ces routines censées se dérouler de
façon indépendantes de VFAT...font partie de VFAT lui-même! Donc le gain de
performances est nul! (et même négatif, vu que ça complique un max!)

DONC, il y a effectivement intérêt à affecter au paramètre
"ConservativeSwapfileUsage" la valeur de 1, mais cela ne supprime en AUCUNE
FAÇON le swap ni son utilisation par le système!


Par contre, la preuve que tu sais dire aussi des choses censées (;+)),
c'est
quand tu écris sur
http://www.pcastuces.com/forum/40435-1.htm
que :
"[...]le mythe selon lequel la taille du swapfile
doit être 2 ou 2.5 fois plus grande que la Ram.
C'est une ineptie puisque le principe même
de la mémoire virtuelle est de pallier à un
manque de Ram. "

Parfaitement EXACT!
Ces coefficients multiplicateurs sont une réminiscence du passé, quand les
PC n'avaient que 4 ou 8 Mo de RAM!

Et j'en profite pour faire un :
Petit RAPPEL sur le fonctionnement du gestionnaire de mémoire :
---------------------------------------------------------------

Codes et données sont chargés en "mémoire virtuelle", qui désigne la
réunion
de la RAM et du Fichier de swap.
Si une page (=zone de 4 ko), nouvelle ou stockée sur disque, est demandée
par un processus, le microprocesseur, qui constate alors que cette page
n'existe pas en mémoire vive, génère (via une "exception", sorte
d'interruption) une "défaillance de page", transmise au VMM (Virtual
Machine
Manager), et la page est alors RECOPIEE du disque vers la RAM.

NB: Une défaillance de page ("page fault" en anglais) n'est pas réellement
une "faute". Cela fait partie de la gestion mémoire, due au VMM incorporé
dans le driver virtuel VMM32.VXD (sous Win9x/ME)

En d'autres termes :
Chaque fois qu'une page du fichier de swap
est demandée en RAM, le VMM procède à un échange
(swap) entre :
- cette page demandée (au départ sur disque)
et
- une autre page (au départ en RAM), moins
"urgente" que la première (parce qu'appartenant
à une appli en arrière-plan à cet instant).

Cette autre page sera donc RECOPIEE de la RAM vers le disque.

Au passage, parler d'"émulation de mémoire" (comme on le voit parfois
écrit)
est un abus de langage!
A tout instant les instructions binaires des différents programmes (applis
et système) ont TOUJOURS lieu dans la RAM (physique, en silicium).

L'enchainement des opérations de swap sont les suivantes :

1)Lancement d'une nouvelle appli : RAM insuffisante !
2)Copie d'une page de 4ko en RAM (d'une appli en
arrière plan) vers le disque de swap
3)Récupération de ces 4ko en RAM pour la nouvelle appli

Et si on a besoin de revenir à l'ancienne appli
qui était en arrière-plan :

4)Copie d'une page de 4k en RAM (d'une autre appli
en arrière plan) vers le disque
5)Récupération de ces 4ko en RAM pour recopie depuis
le disque des 4ko copiés à l'étape 2
6)Exécution en RAM du code contenu dans cette page

Corollaire :
------------
Si une application génère une "invalid page fault" dans un module (avec un
bel écran BLEU), cela signifie que le VMM a essayé de charger EN VAIN une
page à une adresse occupée par le module, lequel fonctionne de toute façon
dans un espace mémoire protégé.

Si le module appartient au noyau de Windows, et non une appli, c'est tout
le
système d'exploitation qui va se "crasher"!

La question réelle est donc :
Comment et pourquoi l'appli a-t-elle pu créer une "invalid page fault"?
Et bien, cela peut être dû à :
- un bug
- une erreur dans l'écriture de l'appli
- une corruption du driver VMM32.VXD
- un problème matériel (RAM défectueuse)
- ...
c'est à dire qu'on N'EN SAIT RIEN !!!!!.

--
May the Force be with You ! La Connaissance s'accroît quand on la partage
--------------------------------------------------------------------------
Jean-Claude BELLAMY - [MVP]
URL : http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr

<mode copy off>


--
Embryon de site : http://gilles.ronsin.free.fr Nouveau: un JukeBox pour
DaemonTool
Mon utilitaire de BDR V1.1.0 : http://gilles.ronsin.free.fr/aregtool.htm
Les gens qui ne rient jamais, ne sont pas des gens sérieux.