Почему проект Rust, выполняющий asyn c сетевой ввод-вывод с использованием Tokio, имеет тысячи записей в файловый дескриптор 5? - PullRequest
Новая
       64

Почему проект Rust, выполняющий asyn c сетевой ввод-вывод с использованием Tokio, имеет тысячи записей в файловый дескриптор 5?

0 голосов
/ 01 марта 2020

Я профилирую свой код для системных вызовов, используя strace. Я нашел некоторые удивительные результаты. Трассировка показывает 47254 однобайтовых записей в файловый дескриптор 5 при передаче по сети 200 МБ данных. 

write(5, "\1", 1)

Что означает эта запись? Что такое FD 5? Откуда это может происходить? Есть ли способ узнать?

Я не очень хорошо разбираюсь в Linux основах.

Вывод ls -lrt /proc/24393/fd

lrwx------ 1 95th 95th 64 Mar  1 20:56 9 -> 'socket:[97676]'
lr-x------ 1 95th 95th 64 Mar  1 20:56 7 -> /dev/random
lr-x------ 1 95th 95th 64 Mar  1 20:56 6 -> /dev/urandom
l-wx------ 1 95th 95th 64 Mar  1 20:56 5 -> 'pipe:[98345]'
lr-x------ 1 95th 95th 64 Mar  1 20:56 4 -> 'pipe:[98345]'
lrwx------ 1 95th 95th 64 Mar  1 20:56 3 -> 'anon_inode:[eventpoll]'
lrwx------ 1 95th 95th 64 Mar  1 20:56 2 -> /dev/pts/0
lrwx------ 1 95th 95th 64 Mar  1 20:56 1 -> /dev/pts/0
lrwx------ 1 95th 95th 64 Mar  1 20:56 0 -> /dev/pts/0

Я проверил, что это труба (хотя это не очень помогло): 

/proc/24393/fd$ lsof | grep 98345
btrs      24393       95th    4r     FIFO               0,11       0t0            98345 pipe
btrs      24393       95th    5w     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24394 95th    4r     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24394 95th    5w     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24395 95th    4r     FIFO               0,11       0t0            98345 pipe
tokio-run 24393 24395 95th    5w     FIFO               0,11       0t0            98345 pipe

1 Ответ

3 голосов
/ 02 марта 2020

Эти записи используются mio (как часть реализации tokio) для пробуждения рабочих потоков, находящихся в системном вызове epoll_wait, когда они пробуждаются чем-то другим, чем триггер файлового дескриптора. Поскольку потоки заблокированы в ОС на системном вызове, для этого требуется какой-то системный вызов, чтобы сообщить ОС разблокировать их. Это может быть вызвано каналом. Если вы видите это, то это говорит о том, что у вас есть рабочие, которые бездействуют. Альтернативой использованию этого системного вызова является сохранение этих потоков в состоянии ожидания при опросе (намного дороже в системных вызовах и времени ЦП) или просто не использовать рабочих вообще, пока они не будут разбужены внешним вводом-выводом (ограничивая ваш параллелизм). Я бы посоветовал вам посмотреть, действительно ли они влияют на производительность или вызваны узкими местами в других местах вашего приложения.

...