J'ai fait quelques tests de performances simples et il semble que la lecture de mon RAID1 soit plus lente que l'écriture:

root@dss0:~# for i in 1 2 3; do dd if=/dev/zero of=/dev/sda bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 192.349 s, 715 MB/s
137438953472 bytes (137 GB) copied, 192.851 s, 713 MB/s
137438953472 bytes (137 GB) copied, 193.026 s, 712 MB/s
root@dss0:~# for i in 1 2 3; do dd if=/dev/sda of=/dev/null bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 257.201 s, 534 MB/s
137438953472 bytes (137 GB) copied, 255.522 s, 538 MB/s
137438953472 bytes (137 GB) copied, 259.945 s, 529 MB/s

Je comprends que dd n'est pas un outil de test de performance, mais ce résultat reste une surprise.

Le système a été construit par le vendeur et possède une carte principale Supermicro avec 16 Go de RAM. Le contrôleur RAID est un MegaRAID 9271-8i avec 1 Go de cache. Il y a 8 disques SAS de 2 To sur un fond de panier SAS-933EL1. Je ne suis pas sûr du câblage, un connecteur du contrôleur va au fond de panier SAS, l'autre va à deux disques SATA qui contiennent le système d'exploitation.

Le RAID1 a été configuré avec cette commande:

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r1 [8:0,8:1,8:2,8:3,8:4,8:5,8:6,8:7] WB NORA Direct -a0
Adapter 0: Created VD 0
Adapter 0: Configured the Adapter!!
Exit Code: 0x00

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 7.275 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 7.275 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives    : 8
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
PI type: No PI
Is VD Cached: No
Exit Code: 0x00

Je m'attendrais à ce que l'accès en lecture soit au moins aussi rapide que l'accès en écriture, peut-être même plus rapide. La vitesse d'écriture de 715 Mo / s semble être proche de la limite de 6 Go d'un seul connecteur SAS / SATA. Est-ce peut-être un problème de configuration ou de câblage avec le fond de panier SAS? La configuration du fond de panier SAS peut-elle être interrogée avec une commande MegaRAID? S'il vous plaît donnez votre avis.

Mettre à jour

Comme l'ont expliqué poige et Peter, les performances de lecture plus lentes que prévu sont probablement dues à la mise en cache du sous-système d'E / S Linux.

Lorsque j'utilise l'indicateur direct dans la commande dd, j'obtiens

root@dss0:~# dd if=/dev/sda of=/dev/null bs=1048576 count=131072 iflag=direct
137438953472 bytes (137 GB) copied, 199.862 s, 688 MB/s

ce qui est bien mieux mais toujours 10% plus lent que la vitesse d'écriture. L'utilisation de oflag = direct n'a pas affecté la vitesse d'écriture.

poige a exactement raison sur le cache d'écriture, mais voici plus de détails.

dd avec des zéros et l'utilisation du cache d'écriture n'est pas la bonne façon de comparer (sauf si vous voulez tester le cache d'écriture bien sûr, qui n'est probablement utile que pour un système de fichiers, pour voir combien il synchronise les métadonnées, crée de nouveaux fichiers, etc. ) (et probablement dd est toujours le mauvais type de référence, mais cela fonctionne pour un test très basique)

Je vous suggère d'utiliser dd avec au moins une des options suivantes:

conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct   -> this will make it skip the OS cache but not the disk cache
conv=sync      -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.

Et n'utilisez pas zéro non plus. Certains matériels / logiciels / micrologiciels intelligents peuvent utiliser des raccourcis si les données sont aussi prévisibles que des zéros. Cela est particulièrement vrai s'il y a une compression que je suppose que vous n'utilisez pas. Utilisez plutôt un fichier aléatoire en mémoire (tel que / dev / shm). urandom est lent, vous devez donc l'écrire quelque part temporairement pour le relire. Créez un fichier aléatoire de 50 Mo:

dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50

Lisez le fichier plusieurs fois pour l'écrire (ici j'utilise cat pour le lire 6 fois):

dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync

rm /dev/shm/randfile

Gardez également à l'esprit que les lectures raid1 sont les plus rapides avec des opérations parallèles, de sorte que les disques peuvent être utilisés indépendamment. Ce n'est probablement pas assez intelligent pour coordonner les disques pour lire différentes parties de la même opération avec différents disques.

La clé de la réponse à votre question est la lecture anticipée . Il était une fois, j'ai également eu ce problème .

IOW, pour des performances de lecture séquentielle optimales, tous les disques doivent être impliqués en permanence dans Input.

Lorsque vous utilisez ddw / o directio(voir man dd), l'opération d'écriture n'est pas effectuée immédiatement, mais passe par le cache du système d'exploitation, de sorte qu'elle a plus de chances d'impliquer tous les disques de manière séquentielle et d'atteindre les performances maximales possibles.