Делюсь интересными технологиями и кейсами в области IT, в том числе и из своей практики.
Публикую новости про новые курсы, а так же промокоды и акции.
Онлайн-школа - https://realmanual.ru
Группа для вопросов - https://t.me/realmanual_group
Post #712
387
Как одна «очередь» в ZFS тормозила мои NVMe
У меня на одном Proxmox-хосте было несколько ZFS-пулов: большой на медленных HDD и два на быстрых NVMe под ноды Kubernetes. Логично: быстрое к быстрому, медленное к медленному.
Во время ночного бэкапа большой ВМ с HDD k8s-ноды на NVMe начинали «залипать». Но метрики дисков были чистые: задержка NVMe 0.3 мс, загрузка 1–2%. Диск не виноват, а тормозит.
Причина оказалась неочевидной. Виртуальные диски в ZFS (zvol) обслуживает общий пул потоков ядра, один на все пулы сразу. Когда бэкап читает HDD, потоки заняты и ждут медленный диск. Запросы к NVMe встают в ту же очередь, хотя сам NVMe свободен. Это как одна касса на два магазина: медленный покупатель задерживает быстрого, а на самих полках пусто. Метрики «диска» этого не показывают: запрос ещё не дошёл до диска.
К чему пришёл:
— перевёл NVMe с ZFS на LVM-thin: запросы идут прямо в блочное устройство, без общей очереди ZFS;
— ZFS оставил на HDD, где его снимки и контрольные суммы нужнее;
Кому интересны подробности, гуглите ключики: zvol_request_sync и zvol_use_blk_mq
Выводы:
1. Быстрые и медленные накопители не стоит гонять через один общий слой, если у него общие очереди.
2. «Диск простаивает, а ВМ тормозит» - повод смотреть выше диска: очереди, потоки, PSI.
3. Метрики await и util нужны, но не всё показывают.
4. По дороге узнал, что PVE не даёт живую миграцию диска на обычный LVM при aio=io_uring: у него могут быть зависания. С LVM-thin такого ограничения нет.
#proxmox #zfs #lvm #nvme #devops
У меня на одном Proxmox-хосте было несколько ZFS-пулов: большой на медленных HDD и два на быстрых NVMe под ноды Kubernetes. Логично: быстрое к быстрому, медленное к медленному.
Во время ночного бэкапа большой ВМ с HDD k8s-ноды на NVMe начинали «залипать». Но метрики дисков были чистые: задержка NVMe 0.3 мс, загрузка 1–2%. Диск не виноват, а тормозит.
Причина оказалась неочевидной. Виртуальные диски в ZFS (zvol) обслуживает общий пул потоков ядра, один на все пулы сразу. Когда бэкап читает HDD, потоки заняты и ждут медленный диск. Запросы к NVMe встают в ту же очередь, хотя сам NVMe свободен. Это как одна касса на два магазина: медленный покупатель задерживает быстрого, а на самих полках пусто. Метрики «диска» этого не показывают: запрос ещё не дошёл до диска.
К чему пришёл:
— перевёл NVMe с ZFS на LVM-thin: запросы идут прямо в блочное устройство, без общей очереди ZFS;
— ZFS оставил на HDD, где его снимки и контрольные суммы нужнее;
Кому интересны подробности, гуглите ключики: zvol_request_sync и zvol_use_blk_mq
Выводы:
1. Быстрые и медленные накопители не стоит гонять через один общий слой, если у него общие очереди.
2. «Диск простаивает, а ВМ тормозит» - повод смотреть выше диска: очереди, потоки, PSI.
3. Метрики await и util нужны, но не всё показывают.
4. По дороге узнал, что PVE не даёт живую миграцию диска на обычный LVM при aio=io_uring: у него могут быть зависания. С LVM-thin такого ограничения нет.
#proxmox #zfs #lvm #nvme #devops
- 👍 9
