Discussion :

[Lekno]

Bonjour à tous, sauriez vous m'indiquer la raison de lutilisation de la mémoire cache à hauteur de3.50 go sur mon windows 7

J'ai bien recherché la signification exact de celle-ci mais sans arriver à en déduire la raison dans mon cas personnel, je travail beaucoup avec la virtualisation. Pour illustrer mpon soucis j'ai fais une capture d'écran des différentes donnés que j'ai pensé être utile au diagnostic. Si d'autres sont necessaires indiquez moi je complèterai le sujet !

Merci par avance pour votre retour !

Pièce jointe 172620

[JML19]

Bonjour

C'est la mise en veille prolongée, le fichier hiberfil.sys utilise beaucoup d'espace.

Il permet de récupérer le PC après une mise en veille prolongée.

[Lekno]

effectivement, c'est résolu avec

en cmd administrateur

Désactive la veille prolongé ainsi que le fichier avec

powercfg -h off

On reactive, le fichier à bien été suprimé

powercfg -h on

[sevyc64]

C'est la mise en veille prolongée, le fichier hiberfil.sys utilise beaucoup d'espace.

Il utilise la même quantité que la ram de la machine puisqu'il contient une copie conforme octet par octet de la ram de la machine au moment de la mise en veille prolongée

[Jipété]

Salut,

Il utilise la même quantité que la ram de la machine puisqu'il contient une copie conforme octet par octet de la ram de la machine au moment de la mise en veille prolongée

T'es sûr de ton coup, là ? Parce qu'on voit bien, sur la copie d'écran fournie, que le fichier pèse 5,4 Go quand la mémoire totale est annoncée à 7,4 Go (bizarre, d'ailleurs, cette valeur, nan ?)

Moi j'aurais dit il contient une copie conforme octet par octet de la ram utilisée, parce que, si tu as 16 Go de mémoire, que tu viens de démarrer la machine (donc la mémoire est presque vide) et qu'on t'appelle pour une urgence, tu mets la machine en hibernation, à quoi bon sauvegarder dans le fichier 14 Go (à la louche) de zéros ?

[sevyc64]

T'es sûr de ton coup, là ? Parce qu'on voit bien, sur la copie d'écran fournie, que le fichier pèse 5,4 Go quand la mémoire totale est annoncée à 7,4 Go (bizarre, d'ailleurs, cette valeur, nan ?)

Normalement oui, ça aurait dû être 7,4Go. Après divers paramétrages peuvent faire varier cela, sans doute, Windows est tellement complexe...
Quant à la valeur des 7,4Go, il faudrait connaitre la valeur "installée" que voit Windows. Une partie de cette mémoire pouvant être verrouillée et inutilisable par le système. C'est le cas notamment lorsque les cartes graphiques n'embraquent pas ou pas assez de mémoires et utilise la "mémoire centrale" comprendre donc la ram du système comme mémoire vidéo.

Moi j'aurais dit il contient une copie conforme octet par octet de la ram utilisée, parce que, si tu as 16 Go de mémoire, que tu viens de démarrer la machine (donc la mémoire est presque vide) et qu'on t'appelle pour une urgence, tu mets la machine en hibernation, à quoi bon sauvegarder dans le fichier 14 Go (à la louche) de zéros ?

Normalement oui, c'est une copie conforme octet par octet. La gestion de la mémoire avec le jeu des réallocations, etc, fait que la mémoire est fragmentée. De plus, Windows n'a pas à un instant t précis, une vision totale de chaque octet utilisé ou pas. Si tu n'utilise que 2Go sur les 16Go, ce n'est pas forcément les 2 premiers Go disponibles qui sont utilisés. Il y a de forte chance qu'ils soient étalés sur la totalité des 16Go.
Le but de l'hibernation est de faire une copie exacte de la totalité de la mémoire système à l’arrêt. Cette copie est rechargée en totalité dans la mémoire au redémarrage à l'emplacement exact pour relancer la machine dans l'état exact qu'elle avait lors de la mise en hibernation, comme si elle n'avait jamais été arrêté.
C'est le parallèle pour la ram du clonage de disque physique ou on ne tient pas compte du formatage et des partitions, on copie à l'identique le disque secteur par secteur, octet par octet.

[sevyc64]

Extrait de ce fil : https://social.technet.microsoft.com...s?forum=win7fr

Bonjour,
J'ai toujours entendu dire que sa taille était celle de la ram.
Mais sur mon W7 32 bits avec 4 Go de Ram j'ai une taille de 2,609 go !
et Aski sur son 64 bits a 2,95 Go

Une réponse ?
Merci d'avance

Je me suis déjà exprimé à ce sujet sur Answers le 26/10/10
Il suffit d'examiner le fichier HIBERFIL.SYS

1) Sa taille
=========
A 1 ou 2 octets près, elle est rigoureusement égale à la quantité de RAM dont dispose Windows.
Je viens de contrôler sur 3 machines différentes, sous XP PRO (1 Go), Vista Home (2 Go) et Win7 Intégrale (4 Go) (32 bits)

Attention : dès qu'on dépasse 2 Go, seule une partie de la RAM est copiée.
Dans le cas de mon Win7, le fichier hiberfil.sys fait pile 2300 Mo.

C'est cette différence avec la RAM physique qui fait dire à certains qu'il y a compression ...

Ils oublient que sous Windows 32 bits, seuls 2 Go sont réservés au mode "User" (à moins de bidouiller avec les commutateur :3GB ou équivalent ...)

S'il y avait compression, ce serait vraiment une coïncidence extraordinaire d'obtenir un nombre rond pour la taille du fichier.

Donc quel serait l'intérêt de compresser un fichier pour avoir au final une taille égale au contenu initial ?
Un taux de compression rigoureusement égal à 1, "moi j'dis ça d'vient gênant!" (et surtout totalement inutile!)
2) Son contenu
============
Là ça se complique un peu, car ce fichier est continuellement utilisé par le processus "SYSTEM", dont le processID est égal à 4, et correspond à l'exécutable "%systemroot%\system32\ntoskrnl.exe".
Si on voulait "tuer" ce processus (ce n'est pas possible, heureusement), on arrêterait Windows !
Et si on arrête la mise en veille prolongée (avec "POWERCFG -H OFF"), cela supprime le fichier HIBERFIL.SYS

Donc il faut ruser !

Pour cela, j'ai fait un clonage sur un disque amovible de ma partiton C: (partition E, et j'ai ensuite examiné le fichier "E:\hiberfil.sys"

Je l'ai ouvert avec mon éditeur hexadécimal favori ("Hex Workshop"), et j'ai pu constater que ce fichier n'avait rien d'un fichier compressé!

P.ex., je me suis "amusé" à rechercher la séquence "MZ" , qui est la signature de tout fichier exécutable Windows.
J'en ai trouvé 9579 instances !!!!
Si quelques unes ne correspondent à rien de connu, par contre un très grand nombre reflètent bien la présence d'exécutables, avec le "stub" bien connu de non exécution en mode DOS, puis la signature Windows PE (Portable Executable), ...

[...]
00017A70 B7 0A 83 B8 0E E0 91 4F F7 5C 38 00 99 09 4D 5A .......O.\8...MZ
00017A80 90 00 39 2F 04 18 00 FF A8 08 B8 38 00 01 00 40 ..9/.......8...@
00017A90 18 00 07 00 07 41 A3 0E 1F BA 0E 00 B4 09 CD 00 .....A..........
00017AA0 00 00 00 21 B8 01 4C CD 21 54 68 69 73 20 70 72 ...!..L.!This pr
00017AB0 6F 67 72 61 6D 20 63 61 6E 6E 6F 74 20 62 65 20 ogram cannot be
00017AC0 72 75 6E 11 60 00 00 20 69 6E 20 44 4F 53 20 6D run.`.. in DOS m
00017AD0 6F 64 65 2E 0D 0D 0A 24 D8 01 01 00 06 B4 0B 28 ode....$.......(
00017AE0 42 D5 65 7B 1F 00 50 64 7B 3B 38 00 90 43 51 04 B.e{..Pd{;8..CQ.
00017AF0 81 DA 38 7B 45 3A 00 6A 7B 43 3A 00 3B 3C 00 3A ..8{E:.j{C:.;<.:
00017B00 7B 5A 3A 00 3F 7A 00 52 69 63 68 B9 01 50 02 02 {Z:.?z.Rich..P..
00017B10 00 50 45 78 4E 01 09 00 4D BD 19 00 18 7B 10 41 .PExN...M....{.A

De la même façon, j'ai recherché les chaines UNICODE "FileVersion", contenues dans la ressource de type "Versioninfo" de tout exécutable ou DLL.

Et là aussi j'en ai trouvé plein , p.ex. (cela concernait la "shell32.dll") :
08DCCB80 77 00 73 00 00 00 00 00 74 00 2A 00 01 00 46 00 w.s.....t.*...F.
08DCCB90 69 00 6C 00 65 00 56 00 65 00 72 00 73 00 69 00 i.l.e.V.e.r.s.i.
08DCCBA0 6F 00 6E 00 00 00 00 00 36 00 2E 00 30 00 30 00 o.n.....6...0.0.
08DCCBB0 2E 00 32 00 39 00 30 00 30 00 2E 00 33 00 34 00 ..2.9.0.0...3.4.
08DCCBC0 30 00 32 00 20 00 28 00 78 00 70 00 73 00 70 00 0.2. .(.x.p.s.p.
08DCCBD0 5F 00 73 00 70 00 32 00 5F 00 71 00 66 00 65 00 .s.p.2..q.f.e.
08DCCBE0 2E 00 30 00 38 00 30 00 37 00 30 00 32 00 2D 00 ..0.8.0.7.0.2.-.
08DCCBF0 31 00 32 00 34 00 30 00 29 00 00 00 30 00 08 00 1.2.4.0.)...0...
08DCCC00 01 00 49 00 6E 00 74 00 65 00 72 00 6E 00 61 00 ..I.n.t.e.r.n.a.
08DCCC10 6C 00 4E 00 61 00 6D 00 65 00 00 00 53 00 48 00 l.N.a.m.e...S.H.
08DCCC20 45 00 4C 00 4C 00 33 00 32 00 00 00 82 00 2F 00 E.L.L.3.2...../.
Rien de compressé là-dedans !!!

Au contraire, un fichier compressé avec une méthode de type LZW n'a évidemment rien à voir avec cela, et à part son nom d'origine en tête de fichier et/ou en fin, il n'y a aucune chaine reconnaissable.
Enfin, devoir décompresser un fichier de (p.ex.) 2 Go, alors qu'on ne dispose encore d'aucun OS, cela me semblerait particulièrement osé au niveau des performances !!!!

Durant cette phase, il y a intérêt à avoir le processus le plus simple et efficace possible, c'est une simple question de bon sens.
Et pour terminer, il y a un point de détail mais important malgré tout comme tu vas voir :
J'ai effectué sur Google une recherche sur la portion de phrase suivante (encadrée par des guillemets) :
"RAM memory that is compressed with an LZXPRESS"

extraite d'un article de Wikipedia.

Et curieusement, j'ai obtenu ... 121 réponses !!!!!
Toutes ne correspondent pas exactement, mais parmi elles les sites ci-dessous reprennent MOT à MOT l'article de Wikipedia !!!!

(ou c'est Wikipedia qui a repris l'article d'un de ces sites!)
forum.eeeuser.com
en.academic.ru
news1st.tk
www.computer-architecture.info
data.lullar.com
www.srilankanewsweb.com
forum.golem.de
forum.zive.cz
...

Voila comment, à partir d'une info comprise de travers, on propage une RALC (Rumeur à la con) !!!!