LINUX.ORG.RU

Ограничить количество очередей для nvme

 , ,


1

2

Использую ubuntu 20.04, в системе большое количество накопителей nvme у которых очереди используют все ядра в системе (96), из-за чего при перегрузе одного накопителя он нагружает все ядра в сотку и начинает виснуть вся система. Нужно на каждый накопитель установить лимит в 4 очереди, а дальше привязать к конкретным ядрам. Как это можно реализовать? Информации в интернете по этому поводу мало, и она не работает, драйвер стандартный.

Если их больше числа линий pci. Они в любом случае будут виснуть. Нужен raid контроллер. А не рейзеры.

red_rain
()

Хм, не могу подсказать твоё решение, но знаю что производительность зависит ещё и от файловой системы. Тот же NTFS через все варианты например очень лагучий.

peregrine ★★★★★
()

Раньше NCQ отключали в /sys/block/devname/device/queue_depth

aidaho@lin:~$ cat /sys/block/sda/device/queue_depth
32

Чёт я сомневаюсь, что тут чего-то можно натюнить лимитом. Если i/o такое быстрое и дорогое для CPU, то нужно больше CPU.

aidaho ★★★★★
()
Ответ на: комментарий от peregrine

Использую сейчас btrfs, раньше с xfs была такая же проблема. Дело не в фс.

SashaShlapik
() автор топика
Ответ на: комментарий от aidaho

Мощнее и больше процессоров сейчас не существует.

SashaShlapik
() автор топика
Ответ на: комментарий от aidaho

ls /sys/block/nvme0n1/

alignment_offset capability device eui events_async ext_range holders integrity mq nsid queue removable size stat trace uuid bdi dev discard_alignment events events_poll_msecs hidden inflight lightnvm nguid power range ro slaves subsystem uevent wwid И

ls /sys/block/nvme0n1/queue/

add_random discard_granularity discard_zeroes_data io_poll io_timeout max_hw_sectors_kb max_segments nomerges optimal_io_size rotational wbt_lat_usec write_zeroes_max_bytes chunk_sectors discard_max_bytes fua io_poll_delay logical_block_size max_integrity_segments max_segment_size nr_requests physical_block_size rq_affinity write_cache zoned dax discard_max_hw_bytes hw_sector_size iostats max_discard_segments max_sectors_kb minimum_io_size nr_zones read_ahead_kb scheduler write_same_max_bytes

Такого варианта не вижу

SashaShlapik
() автор топика

Может, принудительный опрос попробовать? Включается записью в псевдофайл io_poll для выбранных накопителей и выбором желаемого режима через псевдофайл io_poll_delay.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

А как это поможет? Накопители и так под нагрузкой, утилизация 60-90%, backlog 0ms. Но бывают на отдельных накопителях затупы как писал выше из-за которых плохо всей системе

SashaShlapik
() автор топика
Ответ на: комментарий от SashaShlapik

Без понятия. Я никогда не сталкивался с системами хранения с большим количеством NVMe накопителей. Просто читал истории о том, как в некоторых случаях поллинг помогал с тормознутостью. Объяснений не было, но есть подозрения, что это аппаратные проблемы. Вся эта система с прерываниями была построена вокруг идеи о том, что накопители медленные, а они теперь уже не медленные.

Кстати, нагуглил, как задавать число очередей:

# nvme set-feature /dev/nvme0n1 -f 7 -v 0x040004
i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Я также пытался таким образом выставить, но значения не применяются. root@AM1:~# nvme set-feature /dev/nvme0n1 -f 7 -v 0x040004 set-feature:07 (Number of Queues), value:0x040004 root@AM1:~# nvme set-feature /dev/nvme0n1 feature-id required param root@AM1:~# nvme set-feature /dev/nvme0n1 -f 7 set-feature:07 (Number of Queues), value:00000000 root@AM1:~# nvme get-feature /dev/nvme0n1 -f 7 get-feature:0x7 (Number of Queues), Current value:0x7f007f

SashaShlapik
() автор топика

Вам раскрыли потанцевал, а вы опять до 4x ядер ограничиваете. Неблагодарные.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.