optimiser les acces disques

[cro]

je n'ai pas pu m'empecher d'installer debian sur mon ibook et cela m'a permis de lever un point important:
sous linux, un 'hdparm -c 1 -d 1 -m 16 /dev/hda' me permet d'atteindre des vitesses d'acces disque impressionnantes comparées à ce que j'ai sous OSX. (copie de 300Mo en 4 secondes environ, find / performant, etc...)
en moyenne j'ai remarquer une amélioration des performances avec un facteur de 5 à 7
je n'ai pas trouvé hdparm sous OSX, existe-t il un équivalent ? y a t il un autre moyen sous OSX pour tuner le contrôleur disque ?
_________________
MacBookPro 17''

[ch-vox]

excellente question, je vais essayer de chercher en même temps que toi ce genre de manip qui nous permettrait en effet de nous faire gagner un temps fou. j'ai peur que sous X les controleurs soient un peu moins paramétrables...
_________________
Vincent
MacBook Pro Retina 15" mi-2014 Core i7 2,5GHz 16 Go 512 Go (SSD) NVIDIA GeForce GT 750M macOS X 14.5

[mattt-OSX]

concreteemnt, le parametre que tu rentre, ca fait quoi au niveau du controlleur ? ca lui ajoute un cache virtuel ? ca lui enleve ?
_________________
Alu17 1Ghz 1024/60 - Ipod 40Go - iPhone 3G - LaCie 160Go- Fire-i
Rejoignez la communauté de joueurs Nintendo DS à Lyon

[ch-vox]

selon cette page, hdparm ferait partie de l'artillerie de diskutil.app
mais je reste dubitatif...
_________________
Vincent
MacBook Pro Retina 15" mi-2014 Core i7 2,5GHz 16 Go 512 Go (SSD) NVIDIA GeForce GT 750M macOS X 14.5

[cro]

concraitement hdparm te permet, entre autre, d'activer le mode dma (décharge le processeur des transfers de données), activer les I/O en 32 bit (16 bit par défaut sur PC), d'augmenter le nombre de blocs lus en bas niveau, d'activer certains cache, d'utiliser certains mode étendus du contrôleur (augmentation de bande passante, etc...)
je ne vois pas comment diskutil permet de tuner quoi que ce soit hors mis l'activation du journal
sous BSD on peut utiliset sysctl sur la variable hw.atapi.ata_dma et autre truc du genre, mais sous darwin il n'y à rien de cela. un petit sysctl -a pour voir nous montre rien en relation avec les disque...
_________________
MacBookPro 17''

[ch-vox]

[cro]

rien du tout
la tâche ne vas pas être simple, rien dans la doc apple. il faudrai peut-être poser la question sur une mailing list de darwin.
_________________
MacBookPro 17''

[ch-vox]

[cro]

la réponse : MATCH NUL !
je me suis laissé berner comme un débutant par ma non connaissance de HFS.
en fait lorsque tu fais un acces disque, les tampons sont vidés sous HFS, pas sous XFS et EXT2/3 que j'utilise.
en effet, sous linux, si je copie un fichier de 100Mo, l'opération termine (même si les 100Mo n'ont pas été écris sur le disque) lorsque ces 100Mo sont dans les tampons mémoire qui eux son vidés lorsque le système n'est pas chargé ou lorsqu'il n'y à plus de page de cache disponible. sous OSX, l'opération se termine lorsque le fichier et bien écris sur le disque. voila pourquoi je me suis laissé surprendre par la lenteure "apparante" d'OSX.

résultat d'un bench simple avec prise en compte vidage de tampon sur mon iBook 12" dernière génération:

sous Panther


chris@iBook:~$ time dd if=/dev/zero of=testfile bs=1024 count=102400
real 0m3.935s user 0m0.350s sys 0m2.410s
on tourne a 25Mo/s en ecriture contigue

chris@iBook:~$ time cp testfile testfile2
real 0m4.125s user 0m0.020s sys 0m0.990s
on tourne a 24Mo/s en lecture ram et ecriture

note: sans le cache système le cp prend le temps suivant
real 0m11.061s user 0m0.020s sys 0m1.100s
on tourne a 9Mo/s en lecture puis ecriture
(juste à titre d'indication)


sous Linux


avec les paramètres hdparm suivants:
mult_sect_io=16 write_cache=on dma=on io32_support=1

note: je force le sync pour comparer avec OSX
chris@iBook:~$ time {dd if=/dev/zero of=testfile bs=1024 count=102400; sync}
real 0m5.083s user 0m0.050s sys 0m1.330s
on tourne a 20Mo/s en ecriture contigue
sans le sync:
real 0m1.297s user 0m0.050s sys 0m1.240s
on tourne a 77Mo/s en ecriture contigue apparent

chris@iBook:~$ time {cp testfile testfile2; sync}
real 0m4.544s user 0m0.020s sys 0m0.780s
on tourne a 22Mo/s en lecture ram et ecriture
sans le sync:
real 0m0.729s user 0m0.020s sys 0m0.780s
on tourne a 137Mo/s en lecture ram et ecriture apparent


Résultat, Panther fait même légèrement mieux!
mais attention, il fait mieux que Linux uniquement par rapport aux performance de Linux lorsque la mémoire est pleine ou lorsque les fichiers manipulés ne tiennent pas dans les pages de cache.
cela veux dire que Linux est bien plus performant (600%) pour les opérations atomique d'écriture (bref pas en utilisation du système sauf pour l'écriture des fichiers de log (ça peut vraiment rendre un Apache bien plus lent sous OSX que sous Linux dans certains cas), et lorsque une appli écris des fichiers qui tiennent en page de cache)
en imaginant que Linux n'ai plus aucun tampon disponible en RAM, alors OSX s'avère plus performant en écriture (utilisation d'un meilleur pilote IDE/PCI certainement) donc pour des applications de type video/son, OSX est plus performant que Linux (de 2 à 4 Mo/s, soit tout de même 10%)

ce test traite de l'écriture, pour la lecture c'est pareil sauf que là, le fichier doit être entièrement lu depuis le disque, le cache n'interviens donc pas à la première lecture (ce qui nous interresse)
Bref, Linux est meilleur de 600% sur les opérations disque uniquement en écriture lorsque cela tiennent en cache (ceci est due a sa gestion disque via la couche VFS qui exploite vraiment les cache en RAM). OSX est meilleur de par sa gestion du contrôleur disque et offre des acces bruts en écriture/lecture globalement 10% plus rapide que sous Linux.

je déclare OSX winner avec des acces lecture/écriture d'environ 10% de mieux que Linux en général sur mon test qui est très simpliste mais qui donne une idée de "l'optimum"
Linux écris virtuellement des fichiers (dont la taille tien en cache) environ 6x plus vite que sous OSX. (cela n'est plus valable sur un système chargé)

pour répondre à la question: OUI OSX utilise le disque en mode DMA avec write cache et autre...
_________________
MacBookPro 17''

[lpascalon]

En voilà une remarque très instructive...
Merci pour ces tests.
_________________
Ludovic
Evitez de m'envoyer des messages perso sur le forum. Je préfère les mails.

MBP M1 16", 16 Go, SSD 512 Go
iMac 27" 2,9 GHz, 16 Go, 3 To FusionDrive
iMac G4 24" 1,6 Ghz, 1 Go, SuperDrive
iPhone 12 mini 128 Go
iPad Pro 11", iPad mini Cellular...

[cro]

note: sous Linux, si j'écris un fichier puis si je le lis avant que la page de cache ne soit vidée, c'est un acces RAM et non un acces disque qui me permet de lire le fichier, dans ces cas, Linux est tout de même bien meilleur qu'OSX, mais cela intervient-il vraiment souvent ?? franchement je ne pense pas à par sur des bases de données. et comme il est bien rare d'avoir des bases de données dont les tables tiennent en cache...
_________________
MacBookPro 17''

[ch-vox]

j'étais loin du compte. merci pour toutes ces infos !
_________________
Vincent
MacBook Pro Retina 15" mi-2014 Core i7 2,5GHz 16 Go 512 Go (SSD) NVIDIA GeForce GT 750M macOS X 14.5

[pacis]

Une nouvelle fonctionnalité de diskutil avec la 10.4.6 ( spécial Intel !! )
qui permettrai de définir une partition à la volée sans rien détruire ...

et c'est ici => diskutil resize

Vu aussi chez MG
_________________
David

- moi : MBP 15" retina 2.3Ghz 512ssd 16Go + iPad mini + ipad air
- elle : MBA 1,6Ghz V1
- mômes : que des PC !?!, j'ai loupé un truc là

[ch-vox]

bien vu pacis
_________________
Vincent
MacBook Pro Retina 15" mi-2014 Core i7 2,5GHz 16 Go 512 Go (SSD) NVIDIA GeForce GT 750M macOS X 14.5