Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[FreeBSD] ZFS mauvaise perf

8 réponses
Avatar
Patrick Lamaizière
'jour,

Si je compare entre UFS (sur /) et mon /usr qui est dans un zpool j'ai
vraiment de très mauvaises perfs :
UFS : lecture 400 Mo => 1s (à peine) / ZFS : 13 s !
En écriture j'ai un facteur 3.

Une idée ? Je suis en 386 avec 2 Go de RAM et même si c'est pas l'idéal
je trouve curieux d'avoir d'aussi mauvaises perfs.

Aussi la doc de sun indique qu'il vaut mieux éviter les slices comme
vdev et c'est ce que je j'utilise. En fait j'utilise des partitions
BSD dans une slice parce que j'ai juste converti les partitions qui
étaient affectées à /usr /var /tmp en zpool. C'est vrai sous FreeBSD
aussi ?

Merci.

8 réponses

Avatar
Thierry Herbelot
Patrick Lamaizière wrote:

'jour,

Si je compare entre UFS (sur /) et mon /usr qui est dans un zpool j'ai
vraiment de très mauvaises perfs :
UFS : lecture 400 Mo => 1s (à peine) / ZFS : 13 s !



En relisant plus attentivement : je ne crois pas qu'un disque dur "réel"
puisse débiter 400 Mo en 1s (il doit donc y avoir du cache intermédiaire,
ce qui fausse la mesure). Le débit vu sur ZFS ressemble à la "vraie vie",
avec un débit de l'ordre de 30Mo/s cohérent avec des disques SATA modernes.

En écriture j'ai un facteur 3.



Hello,

Je ne reproduis pas le problème en lecture :

% df .
Filesystem 1K-blocks Used Avail Capacity Mounted on
tank/files7 395238656 337776896 57461760 85% /files7
% ll
total 1303495
-rw-r--r-- 1 test test 536642308 9 mar 2001 aa.gz
-rw-r--r-- 1 test test 97952 10 mar 2001 ab.gz
-rw-r--r-- 1 test test 798218119 6 déc 2002 ac.gz
% time dd if¬.gz of=/dev/null bs=1M
761+1 records in
761+1 records out
798218119 bytes transferred in 7.542685 secs (105826787 bytes/sec)
0.007u 0.730s 0:07.54 9.6% 26+1478k 0+0io 0pf+0w

Les débits affichés par "systat -vmstat 1" sont cohérents avec le débit
annocé par dd (avec une pointe vers 47MB/s)

(FreeBSD 7.2, amd64, 4G de RAM, raidz sur 3 disques SATA, contrôleur sur la
carte mère)

Sur une autre machine (i386, 2G, contrôleur SATA PCI Promise), j'ai environ
40Mo/s en lecture.

TfH

Une idée ? Je suis en 386 avec 2 Go de RAM et même si c'est pas l'idéal
je trouve curieux d'avoir d'aussi mauvaises perfs.

Aussi la doc de sun indique qu'il vaut mieux éviter les slices comme
vdev et c'est ce que je j'utilise. En fait j'utilise des partitions
BSD dans une slice parce que j'ai juste converti les partitions qui
étaient affectées à /usr /var /tmp en zpool. C'est vrai sous FreeBSD
aussi ?

Merci.


Avatar
patpro ~ patrick proniewski
In article ,
Thierry Herbelot wrote:

Le débit vu sur ZFS ressemble à la "vraie vie",
avec un débit de l'ordre de 30Mo/s cohérent avec des disques SATA modernes.



heu... J'ai atteint 98 Mo/s sur mon WD Caviar Green d'1To (presque
vide), et il est branché sur un port SATA I (et c'est un 5200 rpm).

30-40 Mo/s c'est plutôt les perf qu'on obtient sur un disque qui est
bien plein.

À titre indicatif, la sortie de diskinfo pour mon WD Caviar Green :

Transfer rates:
outside: 102400 kbytes in 1.082917 sec = 94559 kbytes/sec
middle: 102400 kbytes in 1.204680 sec = 85002 kbytes/sec
inside: 102400 kbytes in 2.118398 sec = 48338 kbytes/sec

Je suis en UFS, et FreeBSD 6.4.

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
Avatar
Patrick Lamaizière
Thierry Herbelot :

En relisant plus attentivement : je ne crois pas qu'un disque dur "réel"
puisse débiter 400 Mo en 1s (il doit donc y avoir du cache intermédiaire,
ce qui fausse la mesure). Le débit vu sur ZFS ressemble à la "vraie vie",
avec un débit de l'ordre de 30Mo/s cohérent avec des disques SATA modernes.



Oui je me suis gourré. Après vérif j'ai environ 30 Mo/s en UFS contre
15 Mo/s en ZFS.

Mais je pense que ça vient en parti de mes vdev : j'ai 3 vdev sur des
partitions BSD :
pool used avail
tank 30,2G 7,79G
ad4p3f 28,2G 7,75G
ad4p3d 997M 19,2M
ad4p3e 997M 19,2M

Avec "zpool iostat", je vois bien que la bande passante se dégrade très
fortement lors qu'il bascule d'une partition à l'autre.

Et visiblement on ne peut pas retirer un vdev du zpool ?

Bon Je vais repasser en UFS en attendant de passer en 64 bits.
Merci.
Avatar
Emmanuel Florac
Le Sat, 28 Nov 2009 11:05:23 +0100, Thierry Herbelot a écrit:

Le débit vu sur ZFS ressemble à la "vraie vie", avec un débit de l'ordre
de 30Mo/s cohérent avec des disques SATA modernes.



Gniii? Les disques actuels les plus pourraves font du 80Mo/s. Les
meilleurs 120 Mo/s (en 7200 tours).

--
My assertion that we can do better with computer languages is a
persistent belief and fond hope, but you'll note I don't actually claim
to be either rational or right. Except when it's convenient.
Larry Wall
Avatar
Pascal Hambourg
Salut,

Thierry Herbelot a écrit :

En relisant plus attentivement : je ne crois pas qu'un disque dur "réel"
puisse débiter 400 Mo en 1s



Patrick n'a pas dit qu'il s'agissait d'un unique disque physique. Ça
doit être faisable avec du RAID ou autre technique de striping.
Avatar
Patrick Lamaizière
Pascal Hambourg :

En relisant plus attentivement : je ne crois pas qu'un disque dur "réel"
puisse débiter 400 Mo en 1s



Patrick n'a pas dit qu'il s'agissait d'un unique disque physique. Ça
doit être faisable avec du RAID ou autre technique de striping.



J'aimerais bien, mais non je m'étais juste gourré :-)
C'est sur un portable et y'a qu'un disque.
Avatar
Thierry Herbelot
Emmanuel Florac wrote:

Le Sat, 28 Nov 2009 11:05:23 +0100, Thierry Herbelot a écrit:

Le débit vu sur ZFS ressemble à la "vraie vie", avec un débit de l'ordre
de 30Mo/s cohérent avec des disques SATA modernes.



Gniii? Les disques actuels les plus pourraves font du 80Mo/s. Les
meilleurs 120 Mo/s (en 7200 tours).



*cohérent*

TfH
Avatar
Ollivier Robert
Dans l'article <hercb0$1ckr$,
Patrick Lamaizière disait :
Et visiblement on ne peut pas retirer un vdev du zpool ?



Non, c'et prévu pour plus tard.

Bon Je vais repasser en UFS en attendant de passer en 64 bits.
Merci.



Je le conseille de toute manière, je n'ai toujours pas réussi à avoir une stabilité correcte en 32 bits. 64 bit, aucun souci.

--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=-
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !