Auslogics Disk Defrag

[Falkra]

Si le planificateur est arrêté, le prefetching aussi.

 

Le prefetching a lieu environ tous les trois jours en moyenne, ou sur commande, ce qui peut vous servir (ou pas) pour vos défragmentations :

Exécuter

Rundll32.exe advapi32.dll,ProcessIdleTasks

(en respectant maj/min)

 

Entre nous, ça ne changera pas grand chose aux performances de la machine.

 

Si vous voulez creuser :

http://pagesperso-orange.fr/doc.jm/Prefetch.htm

[Montano5]

+1 Service du Planificateur des tâches arrêté alors Prefetch désactivé.

 

Le Prefetching a lieu tout le temps (analyse de l'utilisation de l'ordi en temps réel) mais l'optimisation des fichiers par le prefetch a lieu effectivement tout les trois jours.

Pour moi ça a fait passé le boot d'une cinquantaine de secondes (pas de Prefetch, defrag avec JKDefrag) à environ 29 secondes (Prefetch actif avec valeur 3 et defrag avec O&O) Mais ça peut varier avec les ordis.

 

Exemple: Si l'ordi lit au boot ce qui est écrit en bleu dans l'ordre abcd: cccccc aaaaaa bbbbbb ddddddd

Alors le prefetch va fragmenter les parties bleues pour les placer côte à côte et dans l'ordre en début de disque puis le reste à la suite comme ceci: aaaabbbccddccccaabbbdddd

Ca va bien sûr optimiser le boot de l'ordi puisque la tête de lecture ne fait qu'un trajet continue sans saut et sans s'arrêter.

Le dossier prefetch ne contient en aucun cas les fichiers ou une copie des fichiers optimisés. Les fichiers dans le dossier Prefetch sont des fichiers index (layout.ini) et annuaire (les *.pf) qui indiquent les fichiers lus, leur emplacement sur le disque et l'ordre dans lequel ils sont lu. Si vous ouvrez le fichier NTOSBOOT-B00DFAAD.pf par exemple vous pourrez voir tout les fichiers lancés lors du boot et l'ordre dans lequel ils sont lancés. Donc 1 fichier dans le répertoire Windows\Prefetch peut référencer plusieurs fichiers du disque...

Il faut du temps pour que le Prefetch analyse la façon dont on utilise l'ordi et optimise les fichiers correctement. Mais plus on lui laisse du temps et meilleur il est.

 

Si je reprends l'exemple du boot plus haut, un logiciel de défragmentation normal et ce quel qu'il soit va défragmenter les fichiers fragmentés par le prefetch et tout remettre dans l'ordre aaaaaa bbbbbb cccccc ddddddd La tête de lecture va donc devoir sauter tout ce qui est noir (non lu) et va perdre du temps...

 

Attention, je ne dis pas qu'un logiciel de défragmentation est mauvais, il faut toujours défragmenter ses disques régulièrement pour avoir de bonnes perfs. Je dis simplement qu'un logiciel de défragmentation va défaire tout ce que le prefetch a constuit s'il ne sait pas lire le fichier layout.ini ce qui ne servirait à rien.

Donc soit on utilise le prefetch avec un logiciel de défragmentation compatible soit on désactive le prefetch.

[focky]

Bien compris, merci pour l'explication.

[Falkra]

Les défragmenteurs permettent de lire chaque fichier d'un coup de tête de lecture.

Le prefetching permet de lire l'enchaînement logique de programmes d'un coup de tête de lecture.

Deux optiques différentes.

 

Le prefetching agit sur le boot, les défragmenteurs agissent surtout pour tout ce qui vient après. Pourquoi ? On vend mieux un os qui démarre vite, donc on met le maximum de côté (en mode transparent) pour faire démarrer vite.

Certains défragmenteurs payants optimisent le boot avec une autre stratégie, groupent des fichiers windows utilisés pour le boot. Ils font rarement bon ménage avec la stratégie du prefetching. J'en ai essayé plusieurs, la différence n'était pas sensible (c'est à dire relevable sans chrono à la main).

 

Ce que l'on perd avec le prefetching, on le gagne avec les défragmenteurs, et inversement. On parle de dixièmes de secondes ou d'une seconde de différence par boot, mais le temps mis à défragmenter ou faire travailler le prefetcher est bien plus important. Pour rentabiliser ce type d'optimisations, il faut s'accrocher.

 

Tant que votre logiciel vous convient, tout baigne.

[Montano5]

Les défragmenteurs permettent de lire chaque fichier d'un coup de tête de lecture.

Le prefetching permet de lire l'enchaînement logique de programmes d'un coup de tête de lecture.

Deux optiques différentes.

 

Le prefetching agit sur le boot, les défragmenteurs agissent surtout pour tout ce qui vient après. Pourquoi ? On vend mieux un os qui démarre vite, donc on met le maximum de côté (en mode transparent) pour faire démarrer vite.

Certains défragmenteurs payants optimisent le boot avec une autre stratégie, groupent des fichiers windows utilisés pour le boot. Ils font rarement bon ménage avec la stratégie du prefetching. J'en ai essayé plusieurs, la différence n'était pas sensible (c'est à dire relevable sans chrono à la main).

 

Ce que l'on perd avec le prefetching, on le gagne avec les défragmenteurs, et inversement. On parle de dixièmes de secondes ou d'une seconde de différence par boot, mais le temps mis à défragmenter ou faire travailler le prefetcher est bien plus important. Pour rentabiliser ce type d'optimisations, il faut s'accrocher.

 

Tant que votre logiciel vous convient, tout baigne.

 

 

Heu non pas d'accord

Les défragmenteurs fonctionnent par fichiers d'accord? Il peuvent classer ces fichiers par noms, par date, par accès ou simplement pour combler les 'blancs' du disque durs mais jamais ils ne diviseront un fichier en plusieurs partie (le fragmenter).

Or un fichier n'est jamais lu dans son intégralité.

 

Le prefetch lui va fragmenter les fichiers utilisés pour ne prendre que les parties automatiquement lu et les placer de manière contigüe sur le disque. Il va dresser un index des fichiers qu'il a fragmenté (le fichier layout.ini) qui peut servir de liste noire au défragmenteur qui défragmenteront tout les fichiers sauf ceux référencés dans ce fichier pour ne pas altérer le travail du prefetch.

Le Prefetch travail durant les périodes d'inactivité et ne pose donc pas de problème de temps ou de manipulation. Il fonctionne pour le boot, les programmes ou les deux, suivant le choix stipulé dans la bdr.

 

Par contre le Prefetch ne s'occuppe que des 100 fichiers les plus utilisés ( ou 128 pour être exact) donc tout les autres ne sont pas optimisés tant qu'il ne sont pas dans le top 128.

Le Prefetch ne s'occupe pas non plus de l'architecture du disque, peut lui importe si des clusters sont libre entre deux fichiers..

D'où la nécessité d'avoir un logiciel de défragmentation.

 

Les deux optiques peuvent donc être complémentaire sans problème...

C'est d'ailleurs ce qui intéresse le créateur de JKDefrag pour pouvoir l'intégrer dans ses prochaines versions

 

Mais ça oui, tant que le logiciel que vous utilisez vous convient tout baigne

Modifié le 8 mars 2008 par Montano5

[Falkra]

Bonsoir,

 

ok, je n'avais pas vu ça sous cet angle pour le découpage. Merci pour les précisions.

 

Or un fichier n'est jamais lu dans son intégralité.

A quel moment ?

 

Selon le type de fichiers, cela ne sera pas toujours vrai. Si la phase boot est une structure modélisable, les fichiers concernés n'auront pas toujours besoin d'être lus partiellement suivant le schéma établi par le prefetcher. Certains fichiers utilisés lors du boot sont utilisés après cette phase. D'autres parties de ces mêmes fichiers vont servir.

 

Si on utilise une liste noire pour épargner les fichiers sur lesquels le prefetcher a travaillé, on avalise un système fragmenté (positivement), mais lorsque ces fichiers auront besoin d'être parcourus intégralement, on perdra en temps au niveau des accès.

[Montano5]

Bonsoir,

 

 

Selon le type, cela ne sera pas toujours vrai. Si la phase boot est une structure modélisable, les fichiers concernés n'auront pas toujours besoin d'être lus partiellement suivant le schéma établi par le prefetcher. Certains fichiers utilisés lors du boot sont utilisés après cette phase. D'autres parties de ces mêmes fichiers vont servir.

 

Si on utilise une liste noire pour épargner les fichiers sur lesquels le prefetcher a travaillé, on avalise un système fragmenté (positivement), mais lorsque ces fichiers auront besoin d'être parcourus intégralement, on perdra en temps au niveau des accès.

 

C'est pour ça que le prefetch a une période d'analyse, il regarde ce qui est lu, comment, et n'optimise que ce qui est lu toujours dans le même ordre et de la même façon. Il ne semble pas toucher à ce qui est lu aléatoirement. C'est pour ça qu'il optimise plus facilement le boot, c'est toujours lu de la même manière et dans le même ordre. Il optimisera le reste des fichiers fragmentés lors du boot de la même façon s'ils sont lu plus tard... justement parce qu'il a analysé les phases. Exemple, 4 fichiers, les parties en bleue de a et b sont lu au boot , la rouge de a est lu plus tard, et c et d sont lu plus tard avec a:

aaaaaa bbbb cccccc dddddd

Alors le prefetch va faire quelque chose comme ça: aaabbbaaccccddabccdddd

C'est terriblement fragmenté mais c'est toujours rapide à lire.

 

Les fichiers .pf sont justement ces analyses de phases et rien n'empêche le prefetch d'integrer le même fichier dans plusieurs phases.

 

Si le fichier est toujours lu intégralement alors le prefetch n'y touche pas...

Et si un jour ce fichier n'est plus lu intégralement parce qu'on a rajouté un programme qui l'appel comme base mais le remplace pour d'autres fonctions alors le prefetch fragmentera la partie lue pour la placer près de ce programme s'il a remarqué que ce schéma de lecture avait été réalisé plusieurs fois de la même manière.

 

Au début d'XP j'étais sceptique (je fais de l'informatique depuis 89) et le travail du disque dur pendant les périodes d'inactivité m'agaçait, je l'ai donc désactivé.

Puis depuis 6 mois je vois pas mal de questions sur les mythes de l'optimisation d'XP dont le prefetch. Alors je me suis penché sur la question, j'ai discuté avec des personnes comme Jeroen Kessels (sur son forum) qui se posait des questions sur le prefetch sans vraiment comprendre son fonctionnement tout en reconnaissant l'optimisation.

Ca m'a surpris qu'il soit intéressé par la question et qu'il cherche à rendre JKDefrag compatible avec le prefetch alors j'ai tout réactivé et utilisé le programme Boot Time (que j'ai trouvé sur Zebulon d'ailleurs) pour voir si vraiment il y avait amélioration.

 

Et franchement ça marche bien mais il faut lui laisser du temps. Mon boot a mis trois semaines pour arriver à optimisation Boot time m'indiquait 53s. si je me souviens bien avant l'activation du prefetch, puis il est tombé à 47 au bout de quelques jours, puis 45. Maintenant il est autour de 28s...

 

Alors voilà, même si je peux expliquer la théorie du prefetch, je ne peux pas t'expliquer vraiment la manière dont il procède exactement (le lien avec le planificateur des tâches, pourquoi une defrag tout les trois jours ?...)

 

[Falkra]

Exemple, 4 fichiers, les parties en bleue de a et b sont lu au boot , la rouge de a est lu plus tard, et c et d sont lu plus tard avec a:

aaaaaa bbbb cccccc dddddd

Alors le prefetch va faire quelque chose comme ça: aaabbbaaccccddabccdddd

C'est terriblement fragmenté mais c'est toujours rapide à lire.

 

Les fichiers .pf sont justement ces analyses de phases et rien n'empêche le prefetch d'integrer le même fichier dans plusieurs phases.

 

Si le fichier est toujours lu intégralement alors le prefetch n'y touche pas...

 

Ok, poussons la logique.

Ce que je me demandais, c'est si les 4 fichiers sont utilisés seulement pendant la phase de boot ou s'ils peuvent aussi servir après le boot. Je pense à des fichiers d'usage très courant, pas les ntldr - ntdetect.com ou autres boot.ini, mais des fichiers systèmes ou avec le statut de driver/service, qui participent à la phase de boot (là tout dépend à quel moment on l'arrête...) mais aussi après, et sont sollicités en lecture (pas forcément sur leur intégralité), mais après le boot. Dans cette seconde option, le prefetching perd de son intérêt en dehors de la phase strictement consacrée au démarrage, où il est efficace.

[Montano5]

Ok, poussons la logique.

Ce que je me demandais, c'est si les 4 fichiers sont utilisés seulement pendant la phase de boot ou s'ils peuvent aussi servir après le boot. Je pense à des fichiers d'usage très courant, pas les ntldr - ntdetect.com ou autres boot.ini, mais des fichiers systèmes ou avec le statut de driver/service, qui participent à la phase de boot (là tout dépend à quel moment on l'arrête...) mais aussi après, et sont sollicités en lecture (pas forcément sur leur intégralité), mais après le boot. Dans cette seconde option, le prefetching perd de son intérêt en dehors de la phase strictement consacrée au démarrage, où il est efficace.

 

Justement, je ne sais pas

Je pense que tout dépend de la stratégie utilisée pour le prefetch (boot, programmes, les deux), de la fréquence d'utilisation de ces phases (est-ce que la lecture de ces fichiers est effectuée plus souvent que la phase de boot, est ce que les deux phases rentrent dans le top 128), et des parties utilisées par la lecture des deux phases.

Si les parties sont différentes, pas de problème, on scinde en autant de parties qu'il faut et qu'on classe par autant phase. Si ce sont les mêmes parties il faut bien en privilégier une au détriment de l'autre et le prefetch privilégierait toujours la mieux classée dans le top 128.

Je me suis demandé si le prefetch ne pousserai pas le vice jusqu'à dupliquer certaines parties de fichiers pour la rendre disponible sur plusieurs phases Mais j'ai pas trouvé d'info dessus et ça poserai un problème de MFT...

Ceci dit, je pense que c'est effectivement dans ce genre de cas que le prefetch atteint ses limites.

 

La limitation à 128 fichiers-phases permet de limiter ce genre de problème mais limite aussi l'efficacité du prefetch à une partie infime des fichiers qu'on utilise. D'où l'utilité d'avoir un bon logiciel de défragmentation qui puisse brosser le prefetch dans le sens du poil tout en consolidant bien les fichiers derrière

 

edit: L'utilisateur au final fait un choix, pour le boot tapez 1, pour les applications tapez 2, pour un mélange avec des hauts et des bas tapez 3 pour ne pas utiliser de prefetch tapez 0

Modifié le 9 mars 2008 par Montano5

[douds]

Bonjour tous, bonjour Montano5,

D'après toi, comment fonctionne le Prefetch ?

j'en avais une idée complètement fausse et je te remercie vivement de tes explications.

 

Seulement, voilà, maintenant je suis un peu paumé et je ne sais plus si je dois garder le Prefetch et si oui avec la valeur 2 ou 3.

 

Si je le garde, je comprends bien que mon défragmenteur défait ce que fait le Prefetch, qui ne sert donc plus à grand chose.

Donc, dans mon cas, je pense qu'il faut mieux que je désactive ... je ne suis pas à quelques secondes près au démarrage.

 

J'ai lu un peu partout que les forumeurs conseillaient la valeur 2, alors que M$ la valeur 3.

Qu'en penses-tu ?

En sachant qu'il faut un défragmenteur qui respecte le travail du Prefetch, si j'ai bien compris ?

 

J'ai la valeur 0 dans EnableAutoLayout

et 1 dans BootOptimizeFunction

est-ce que ce n'est pas contradictoire ?

 

PS : encore merci d'avoir "insisté"

 

=================================

Oups, autre chose stp,

 

comment désactiver l'analyse d'accès des fichiers (NTFSLastAccessUpdate) ?

Modifié le 9 mars 2008 par douds