Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Mac OS Autres OS Mac OS X Tester les perfs des disques durs

Tester les perfs des disques durs

39 réponses
Avatar
pehache
Bonsoir,

je cherche un utilitaire pour tester les perfs des disques durs sur Mac
OS X (10.6). Gratuit si possible.

Merci,

--
pehache
Signaler un problème avec ce contenu

9 réponses

Supprimer
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
1 2 3 4
Avatar
J.P
In article ,
pehache wrote:

A part ça, depuis que je suis passé de 4 à 12Go de RAM je n'ai plus de
freezes intempestifs.



Je n'ai pas tout suivi.
Avec Lion ces 12Go ? sur quelle machine ?

--
Jean-Pierre
Avatar
pehache
Le 03/12/11 01:53, J.P a écrit :
In article,
pehache wrote:

A part ça, depuis que je suis passé de 4 à 12Go de RAM je n'ai plus de
freezes intempestifs.



Je n'ai pas tout suivi.
Avec Lion ces 12Go ? sur quelle machine ?




Non, sous Snow Leo, sur un iMac 2011. J'avais parfois des freezes, et
sans doute que c'était parce que ça swappait.

--
pehache
Avatar
Matt
On Ven 02 décembre 2011, 23:39,
pehache wrote:

Juste après le boot et l'ouverture de session, j'ai une "mémoire
virtuelle" affichée qui fait déjà 146Go. J'ai du mal à comprendre une
telle taille.



Cette taille n'a que peu d'importance dans ce contexte car elle est
virtuelle (aucune page n'est adressée à la mémoire physique). C'est une
évaluation *virtuelle* des besoins en mémoire mais aucunement que sa
totalité serait chargée d'un coup.

Évidemment si tu étais développeur tu serais enclin a diminuer
l'allocation virtuelle (en ne chargeant que le strict nécessaire dans
ton programme lors de son premier lancement).

La mémoire virtuelle c'est bien l'ensemble des objets mappés dans
l'espace adressable par le kernel, sachant qu'ils peuvent être dans la
mémoire physique ou sur le disque ?



Non.
L'espace d'adressage de la mémoire virtuelle reste... virtuel tant que
le programme n'accède pas à des pages qui sont dans cet espace.

Le processeur et le mmu maintiennent une table d'allocation qui
permettra d'allouer les pages virtuelles d'un programme, au besoin, dans
l'espace adressable de la mémoire physique.

Et le swap c'est bien les pages de mémoire virtuelle que le kernel a
besoin de dégager temporairement de la mémoire physique, mais qui ne
proviennent pas du mappage d'un fichier déjà existant ?



Non car l'espace virtuel alloué au programme lui est toujours disponible
(car il est... virtuel).

Le swap a deux sens dont l'un indique un manque de mémoire physique (le
fameux « paging out »).

Lorsqu'un programme tente d'accéder à une adresse mémoire qui n'est plus
chargée dans la mémoire physique, un « page fault » survient.

À ce moment, si aucune page n'est libre dans la mémoire physique, le
gestionnaire du « page fault » va libérer une page existante de la
mémoire physique (il va la placer dans le « backing store » : le disque,
ndlr).
Ce processus de libération de page est appelé « paging out ».

Le processus inverse est appelé « paging in ».

A part ça, depuis que je suis passé de 4 à 12Go de RAM je n'ai plus de
freezes intempestifs.



Normal car tu diminues les écritures dans le « backing store » (et
indirectement le besoin de recharger des pages du backing store, donc
accès disque obligatoires, dans la mémoire physique).

--
Un meurtre de sang froid : Un ice crime
Avatar
gilbert.olivier
pehache wrote:

Le 20/11/11 22:21, Matt a écrit :
> On Dim 20 novembre 2011, 20:56,
> pehache wrote:
>
>>> La mémoire virtuelle n'existe pas (d'où son nom) mais représente
>>> potentiellement la taille requise pour l'application (taille qui
>>> est dynamique, ndlr).
>
>> C'est pas clair vos histoires :-)
>
> La notion de mémoire virtuelle peut paraître vague, je l'avoue.
> Car l'on confond souvent mémoire virtuelle et swap.
>
> Tu as tout d'expliquer dans le paragraphe « About the Virtual Memory
> System », dont je j'ai donné le lien.
>

Juste après le boot et l'ouverture de session, j'ai une "mémoire
virtuelle" affichée qui fait déjà 146Go. J'ai du mal à comprendre une
telle taille.

La mémoire virtuelle c'est bien l'ensemble des objets mappés dans
l'espace adressable par le kernel, sachant qu'ils peuvent être dans la
mémoire physique ou sur le disque ? Et le swap c'est bien les pages de
mémoire virtuelle que le kernel a besoin de dégager temporairement de la
mémoire physique, mais qui ne proviennent pas du mappage d'un fichier
déjà existant ?


Non.

Comme le dit Matt dans le message précédent, tu confonds mémoire
virtuelle et swap (qui lui n'à rien de virtuel ;-)) ).

A part ça, depuis que je suis passé de 4 à 12Go de RAM je n'ai plus de
freezes intempestifs.



Tant mieux ;-)

Déjà entre 4 et 8 (sur deux macbookpro) c'est le jour et la nuit sur la
taille du swap ;-)
--
Gilbert
Avatar
Matt
On Sam 03 décembre 2011, 14:18,
Gilbert OLIVIER wrote:

Tant mieux ;-)

Déjà entre 4 et 8 (sur deux macbookpro) c'est le jour et la nuit sur la
taille du swap ;-)



Je confirme.
Après beaucoup de pageouts sur un macbookpro7,1 qui fait office de
serveur à tout faire pour mon usage personnel, l'augmentation de 4 à 8Go
m'a permis de diminuer la fréquence du swapping out de façon drastique.

--
Pharmacie : Confiserie pour vieux
Avatar
pehache
Le 03/12/11 13:56, Matt a écrit :
On Ven 02 décembre 2011, 23:39,
pehache wrote:

Juste après le boot et l'ouverture de session, j'ai une "mémoire
virtuelle" affichée qui fait déjà 146Go. J'ai du mal à comprendre une
telle taille.



Cette taille n'a que peu d'importance dans ce contexte car elle est
virtuelle (aucune page n'est adressée à la mémoire physique). C'est une
évaluation *virtuelle* des besoins en mémoire mais aucunement que sa
totalité serait chargée d'un coup.



Une évaluation basée sur quoi ?


La mémoire virtuelle c'est bien l'ensemble des objets mappés dans
l'espace adressable par le kernel, sachant qu'ils peuvent être dans la
mémoire physique ou sur le disque ?



Non.
L'espace d'adressage de la mémoire virtuelle reste... virtuel tant que
le programme n'accède pas à des pages qui sont dans cet espace.

Le processeur et le mmu maintiennent une table d'allocation qui
permettra d'allouer les pages virtuelles d'un programme, au besoin, dans
l'espace adressable de la mémoire physique.

Et le swap c'est bien les pages de mémoire virtuelle que le kernel a
besoin de dégager temporairement de la mémoire physique, mais qui ne
proviennent pas du mappage d'un fichier déjà existant ?



Non car l'espace virtuel alloué au programme lui est toujours disponible
(car il est... virtuel).

Le swap a deux sens dont l'un indique un manque de mémoire physique (le
fameux « paging out »).

Lorsqu'un programme tente d'accéder à une adresse mémoire qui n'est plus
chargée dans la mémoire physique, un « page fault » survient.

À ce moment, si aucune page n'est libre dans la mémoire physique, le
gestionnaire du « page fault » va libérer une page existante de la
mémoire physique (il va la placer dans le « backing store » : le disque,
ndlr).
Ce processus de libération de page est appelé « paging out ».

Le processus inverse est appelé « paging in ».




Le swap ça je comprends bien. C'est cette histoire de mémoire virtuelle
que je trouve pas claire, là.

Je "connais" deux façons d'utiliser l'espace mémoire adressable :
- classique (malloc() en C); si on dépasse la RAM physique, le système
utilise le swap
- les fichiers mappés en mémoire (je ne parle pas du cache disque)

Je voyais la mémoire virtuelle comme l'ensemble de la mémoire allouée
classiquement + les fichiers mappés ouverts. Sauf que juste après le
démarrage je ne vois pas bien comment on peut avoir plusieurs dizaines
de Go...

--
pehache
Avatar
blanc
pehache wrote:

>
> Cette taille n'a que peu d'importance dans ce contexte car elle est
> virtuelle (aucune page n'est adressée à la mémoire physique). C'est une
> évaluation *virtuelle* des besoins en mémoire mais aucunement que sa
> totalité serait chargée d'un coup.

Une évaluation basée sur quoi ?



Amha le total de la mémoire qu'utiliseraient tous les processus ouverts
s'ils étaient effectivement complètement chargés en mémoire.

Le swap ça je comprends bien. C'est cette histoire de mémoire virtuelle
que je trouve pas claire, là.

Je "connais" deux façons d'utiliser l'espace mémoire adressable :
- classique (malloc() en C); si on dépasse la RAM physique, le système
utilise le swap



En fait ce n'est pas vraiment à ce niveau qu'intervient le swap...

- les fichiers mappés en mémoire (je ne parle pas du cache disque)



Comme expliqué par Matt, le swap intervient chaque fois qu'il y a un
défaut de page. Pas forcément lors d'une allocation.

Je m'explique : A un instant donné, un certain nombre de processus
s'exécutent dans la mémoire. Mais il ne sont pas en général complètement
chargés. Si un programme doit exécuter une instruction ou accéder à une
donnée d'une page qui n'est pas en mémoire, alors il y a défaut de page.
Le système va donc charger cette page. Mais s'il n'y a pas de place
disponible pour le faire, alors il va commencer par décharger une page
existante (*).
Si c'est une page qui est uniquement en lecture (page de programme),
elle est simplement écrasée par la nouvelle page (car la page existe
déjà sur le disque). Sinon elle est copiée sur le disque dans un fichier
de swap.

Lors d'une allocation (malloc() en C), celle-ci peut éventuellement être
faite dans les pages en mémoire. Sinon il y a création de nouvelles
pages virtuelles. Mais pas encore dans le swap : ce n'est que lorsque le
programme écrira dans ces pages qu'elles seront mises dans le swap.


(*) si possible une qui a peu de probabilité d'être nécessaire
prochainement. Et c'est tout le problème des algorithmes de changement
de pages.

Je voyais la mémoire virtuelle comme l'ensemble de la mémoire allouée
classiquement + les fichiers mappés ouverts.



En gros c'est bien ça.
Mais en fait il y a plusieurs types de mémoire virtuelle suivant le
système d'exploitation. Ce que j'ai décrit ci-dessus est la mémoire
virtuelle paginée telle qu'elle existe sous Unix.
Eric L. décrit celle de NextStep qui est très similaire ici :
<http://www.levenez.com/NeXTSTEP/Memoire.html>

Historiquement la mémoire virtuelle n'était pas paginée : c'était les
processus entiers qui étaient swappés sur le disque quand on avait
besoin de place pour un autre processus.

La mémoire virtuelle de Mac OS classique fonctionnait différemment
aussi.

Sauf que juste après le
démarrage je ne vois pas bien comment on peut avoir plusieurs dizaines
de Go...



Beaucoup de process sont lancés au démarrage. Effectue donc dans le
Terminal la commande suivante :
ps aux
et ceci juste après le démarrage.

Compte le nombre de lignes
Compte la somme de nombres de Ko de la colonne VSZ ( Virtual size)

--
JiPaul.
/ /--/--// Jean-Paul Blanc
|/| L | quelquepart en (somewhere in)
/|| = ||| FRANCE
Avatar
Matt
On Jeu 15 décembre 2011, 23:36,
pehache wrote:

Une évaluation basée sur quoi ?



Sur... les besoins requis par un programme (les librairies, les
adressages déclarés mais non initialisés par le code, etc.).

Le swap ça je comprends bien. C'est cette histoire de mémoire virtuelle
que je trouve pas claire, là.

Je "connais" deux façons d'utiliser l'espace mémoire adressable :
- classique (malloc() en C); si on dépasse la RAM physique, le système
utilise le swap
- les fichiers mappés en mémoire (je ne parle pas du cache disque)



Tu confonds encore allègrement le swap et la mémoire virtuelle, t'es pas
croyable toi.

L'adressage reste dans l'espace virtuel tant que celui-ci n'est pas
requis.

Je voyais la mémoire virtuelle comme l'ensemble de la mémoire allouée
classiquement + les fichiers mappés ouverts. Sauf que juste après le
démarrage je ne vois pas bien comment on peut avoir plusieurs dizaines
de Go...



Dommage car c'est justement l'avantage de la mémoire virtuelle; pouvoir
allouer des pages mémoires sans être limité par la taille de la mémoire
physique.

--
Pruneau : Synonyme de personne âgée. Qui est ridé et qui fait chier
Avatar
pehache
Le 16/12/11 14:29, JiPaul a écrit :
pehache wrote:


Cette taille n'a que peu d'importance dans ce contexte car elle est
virtuelle (aucune page n'est adressée à la mémoire physique). C'est une
évaluation *virtuelle* des besoins en mémoire mais aucunement que sa
totalité serait chargée d'un coup.



Une évaluation basée sur quoi ?



Amha le total de la mémoire qu'utiliseraient tous les processus ouverts
s'ils étaient effectivement complètement chargés en mémoire.

Le swap ça je comprends bien. C'est cette histoire de mémoire virtuelle
que je trouve pas claire, là.

Je "connais" deux façons d'utiliser l'espace mémoire adressable :
- classique (malloc() en C); si on dépasse la RAM physique, le système
utilise le swap



En fait ce n'est pas vraiment à ce niveau qu'intervient le swap...

- les fichiers mappés en mémoire (je ne parle pas du cache disque)



Comme expliqué par Matt, le swap intervient chaque fois qu'il y a un
défaut de page. Pas forcément lors d'une allocation.



Oui OK, j'ai fait un raccourci, en supposant qu'on utilisait la mémoire
tout de suite après son allocation, ce qui n'est pas forcément le cas.


Je voyais la mémoire virtuelle comme l'ensemble de la mémoire allouée
classiquement + les fichiers mappés ouverts.



En gros c'est bien ça.
Mais en fait il y a plusieurs types de mémoire virtuelle suivant le
système d'exploitation. Ce que j'ai décrit ci-dessus est la mémoire
virtuelle paginée telle qu'elle existe sous Unix.
Eric L. décrit celle de NextStep qui est très similaire ici :
<http://www.levenez.com/NeXTSTEP/Memoire.html>

Historiquement la mémoire virtuelle n'était pas paginée : c'était les
processus entiers qui étaient swappés sur le disque quand on avait
besoin de place pour un autre processus.

La mémoire virtuelle de Mac OS classique fonctionnait différemment
aussi.

Sauf que juste après le
démarrage je ne vois pas bien comment on peut avoir plusieurs dizaines
de Go...



Beaucoup de process sont lancés au démarrage. Effectue donc dans le
Terminal la commande suivante :
ps aux
et ceci juste après le démarrage.

Compte le nombre de lignes
Compte la somme de nombres de Ko de la colonne VSZ ( Virtual size)




Vu comme ça, certes...

Mais j'ai quand même du mal à me l'expliquer. Les VSZ des process font
facilement plusieurs Go. Or les exécutables eux-mêmes sont plutôt de
l'ordre de quelques dizaines de Mo sur le disque. D'où vient donc toute
cette mémoire virtuelle ? Qu'un process n'utilise pas immédiatemment la
mémoire qu'il alloue, OK, mais même plusieurs jours après le boot la
situation est la même...
1 2 3 4