Как активировать «мультипроцессность» при использовании команд по конвейеру?

Мой эксперимент говорит об обратном. Попытаюсь описать более детально ситуацию.

cmd1 создает по одному воркеру на ядро, которые производят данные и возвращают их с помощью пайпа. Далее cmd1 передает данные по конвейеру в cmd2, которым является sort.

В результате cmd1 и sort используют одно ядро процессора (sort 90%, cmd1 10%). Поэтому cmd1 не успевает обслуживать свои воркеры и производительность системы катастрофически снижается.

То есть, даже вариант cmd1 > file && sort file работает в десяток раз быстрее. Все это указывает на то, что таки делят процессы между собой ресурсы одного ядра и htop это подтверждает.

Извиняюсь, немного сумбурно.

В описанном примере sort потребляет значительную долю процессорного времени одно ядра, а cmd1 достается меньшая часть (пропорционально). В результате cmd1 не успевает обслуживать воркерыы, которые производят данные. htop показывет 90/10 sort/cmd1. Но если сделать так
cmd1 > file && sort file
то никаких потерь производительности нет.

Убираю из конвейера sort - все ядра загружены на 100%. Добавляю sort - все ядра простаивают, работает только sort и немного cmd1 (остальные процессы зависят от cmd1).

Мой эксперимент говорит об обратном.

Антон Кутузов, вот вам эксперимент, который говорит о прямом:
while : ; do : ; done | while : ; do : ; done
Этот пайплайн нагружает систему ровно на 200%.

Если вас смущает отсутствие ввода/вывода, то вот пример со вводом/выводом:

while : ; do echo 1 ; done | pv | while : ; do read ; done

Этот пайплайн нагружает систему на 180%

Если ваш пайплайн нагружает систему меньше, значит либо писатель не пишет достаточно данных, чтобы нагрузить читателя на 100%, либо читатель читает слишком медленно и тормозит писателя.

jcmvbkbc, да, действительно, вы правы. Но что делать в моей ситуации:

Убираю из конвейера sort - все ядра загружены на 100%. Добавляю sort - все ядра простаивают, работает только sort и немного cmd1 (остальные процессы зависят от cmd1).

Похоже sort читает медленнее, чем пишет cmd1. Благодарю. Но исправить эту ситуацию, получается, можно только используя временный файл?

Но исправить эту ситуацию, получается, можно только используя временный файл?

Антон Кутузов, а sort и так использует временный файл, когда получает ввод из stdin. Лучше вы сами, как вам надо, чем он, как попало.

Антон Кутузов, кстати, у sort есть ключ --parallel=N который может помочь, если есть достаточно процессорной мощности.

jcmvbkbc, Большое спасибо!

Антон Кутузов, вы ещё не учли, что sort начнет работать лишь после завершения cmd1. До этого он просто буферезирует данные. Он не может отдать дальше отсортированные данные, т.к. для этого требуются все данные.

fshp, Для меня было абсурдом, что чтение из пайпа может быть медленнее, чем чтение из файла. Поэтому я даже не рассматривал такой вариант, а сделал вывод, что в данном случае процессы делят ресурсы одного ядра. Возможно информация о размере файла позволяет sort быть более производительным. Иначе у меня больше нет предположений.

fshp, а может быть это ошибки в реализации sort. Например, недавно обнаружил для себя, что shuf ломает данные переданные по конвейеру, но при этом корректно работает с файлами. Похоже на то, что работу с файлами писали одни люди, а работу с пайпами уже другие :)

Антон Кутузов, sort при работе с файлами использует mmap, что гораздо эффективнее пайпов.

fshp, даже если mmap, то все равно используются операции чтения с диска. Пусть и без промежуточной буферизации, но это значительно медленнее, чем читать из пайпа.

sort при работе с файлами использует mmap

https://github.com/coreutils/coreutils/blob/master...
fshp, только чтение, никаких mmap

jcmvbkbc, вы правы. Более того, по выводу strace видно, что sort использует mmap наоборот при чтении из пайпа, а из файла - нет.
Возможно разница в производительности кроется в fadvise, который для пайпа возвращает ошибку и никак не влияет на поведение.

Ну а вообще пайпы медленные.

➜ ~ dd if=/dev/zero count=2048 bs=2M of=/dev/null
2048+0 records in
2048+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 0.229433 s, 18.7 GB/s
➜ ~ dd if=/dev/zero count=2048 bs=2M | dd of=/dev/null bs=2M
2048+0 records in
2048+0 records out
2048+0 records in
2048+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 3.66622 s, 1.2 GB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 3.66578 s, 1.2 GB/s