Avez-vous essayé avec des blocs plus petits ?
Lorsque j'essaie sur mon propre poste de travail, je note une amélioration successive lors de la réduction de la taille du bloc. Ce n'est que de l'ordre de 10% dans mon test, mais toujours une amélioration. Vous recherchez 100 %.
Comme il s'avère que des tests plus approfondis, de très petites tailles de bloc semblent faire l'affaire :
j'ai essayé
dd if=/dev/zero bs=32k count=256000 | dd of=/dev/null bs=32k
256000+0 records in
256000+0 records out
256000+0 records in
256000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 1.67965 s, 5.0 GB/s
, 1.68052 s, 5.0 GB/s
Et avec votre
d'originedd if=/dev/zero bs=8M count=1000 | dd of=/dev/null bs=8M
1000+0 records in
1000+0 records out
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 6.25782 s, 1.3 GB/s
, 6.25203 s, 1.3 GB/s
5,0/1,3 =3,8, c'est donc un facteur important.
Il semble que les canaux Linux ne cèdent que 4096 octets à la fois au lecteur, quelle que soit la taille des écritures du rédacteur.
Donc, essayer de bourrer plus de 4096 octets dans un tube déjà bourré par appel système write(2) ne fera que bloquer l'écrivain, jusqu'à ce que le lecteur puisse invoquer les multiples lectures nécessaires pour extraire autant de données du tube et faire n'importe quel traitement il a en tête de faire.
Cela me dit que sur les CPU multi-cœurs ou multi-threads (quelqu'un fait-il encore un seul cœur, un seul thread, CPU ?), On peut obtenir plus de parallélisme et donc des temps d'horloge écoulés plus courts en ayant chaque écrivain dans un pipeline seulement écrire 4096 octets à la fois, avant de revenir au traitement ou à la production de données qu'il peut effectuer pour créer le bloc 4096 suivant.