Вопрос или проблема
У меня есть /var/lib/docker на наборе данных zfs, и docker создает много устаревших наборов данных.
Теперь, когда я пытаюсь запустить любое приложение в docker, оно застревает на создании клонов zfs.
На iostat диск не имеет нагрузки (другие наборы данных на том же диске работают идеально).
Я использую последнюю версию zfs на ubuntu-server 24.04
Процессы:
root 523546 0.0 0.0 12864 5760 ? S 05:31 0:00 zfs clone -p -o mountpoint=legacy docker/56ce854c8077f1b78bc27a72301c351a3377ef93b26c272b8729ade53c2ad9e3@571988438 docker/f42fd5e6ca61cf0021d93de60d18c6048145a22807a7136254336ce58487f3e0-init
root 523653 0.0 0.0 12864 5760 ? S 05:31 0:00 zfs clone -p -o mountpoint=legacy docker/fafbcb1906102218b051c28d9ab9bcb4979673b50c7c26c2586eb1cfa3b1b6af@658347981 docker/c3c033bd2555c37f6f365b2c9068fda4a113a1edd2a228642ce9185c485dd935
root 524165 0.0 0.0 12864 5760 ? S 05:32 0:00 zfs clone -p -o mountpoint=legacy docker/0ca7a7988df48f81c04a96c2e763f61257ad7d6903fb448f1645e7ad4e235a91@698585 docker/d684a83efe44309321e389f8621724e800befbbe4c5d53f703ae6982883afee8
root 530363 0.0 0.0 12864 5760 ? S 05:36 0:00 zfs clone -p -o mountpoint=legacy docker/y2z2uh4qyplkoe6sxadwoe831@843581816 docker/f4f4f2bd9ffdd4cc5dc945ed7ab90f72309fef614a922087ca25393e130f97a4-init
На наборе данных docker у меня их много (около 1700 после docker system prune -a):
docker/0e17e764543d4e6550f73800f2b25f3fa8aa9e8bcbb08d07d9486997ca916a58 381K 115G 229M legacy
docker/0e450f6ad01e0bebd1d0ecb8a065dd76ebf37bdf389daa834b496a3babf66c4c 60.5K 115G 43.7M legacy
docker/0e807120a17af013fdfbdf88a1d28219076ae598b7fd056b6edf5cd8df46dab0 34K 115G 5.96M legacy
docker/0ea5b851be8e8cfca8d42086d8cf23ef643c1ee000553d2cee9861f2754b66cd-init 42K 115G 18.0M legacy
docker/0eb9c4b47bc2f522f889ebcd25a073958ffda0ee9219f2163823be7235d54529 152K 115G 992K legacy
docker/0f69d8c78c76a17910efa648d93d59c431b9d59d9231247ecfa2cf61e5bc02e3 88K 115G 244M legacy
docker/0f8ec22be3b285eddfdc0f772ab9e13e8fbe7c2c478e4b6c2b6d0c28b39db3c6 64K 115G 147M legacy
docker/0fb7867f6d678525aae455263388a3af4a433638628edd68bee83816c7253a5c 35.8M 115G 67.9M legacy
docker/0fbb32a8713abead800a2934b136ee6a3bbe22f9ec41e0d0381bd6215df816fd 28.5K 115G 11.3M legacy
docker/0fdfe17ef326fa3c580c8ca0afa855961d2b0f437afcccb4a1944188df6ef310 92.5K 115G 516M legacy
docker/0m2m58tuu9kp0kc30y4cxnmli 78K 115G 70.3M legacy
docker/1016063724ddd47f666941b9692a499f3e69e7348aad2d3bde9669f7c010a70b 34.2M 115G 38.7M legacy
docker/104ab2c068c0d0e18f1b7fce8e0a415fb0f95ee193a0a2bdd7f0f78701786205-init 74K 115G 658M legacy
docker/1053dff916ce902c1aed35c3903fdcbebcd25919608303ab4ee51f85221068e3 11.8M 115G 145M legacy
docker/10ace538d545e152cf5bdcef21ec9fc1e6bdd72028395fbaa7a3be2e6845b064-init 77K 115G 360M legacy
docker/10c989bf001a2e64f2fed522d4bef7ccfbf29254e91b19e68547340afcf478ee 32.8M 115G 32.8M legacy
docker/11041c719f63c0bf9bb309e189b471892e0accd550aea1b169adbf5f429e857b-init 56K 115G 42.4M legacy
docker/113xgujmvfenlx64f5np7xbst 16.6M 115G 70.3M legacy
docker/11405fa928d1834df75d35ac31dac8ce4141ce9447c575783627e520d97ba573 55.5K 115G 69.8M legacy
docker/1143eb99a3c1de5b07fd134f6678f43467800b11d735472f04b3e06fa10f5d88 107M 115G 153M legacy
docker/114a0edcfdabec21ae0430a58859e9deabd54f2a62a90bce78aa64421e0655f8-init 72K 115G 658M legacy
docker/118cdcebf5c2076be9b0ed71524a4e711c19fb2bc226e51fd0b064298d496902 94K 115G 347M legacy
docker/11a84d6e76f3bf2b227396630bc894bbb3e299acb1be97433ce368d5cd099091 54.5K 115G 110M legacy
docker/11b54b5f71d55af8d356228d3eceefacd9c8b8eaff8885ae9204810ef00a2a17 10.6M 115G 262M legacy
docker/11c5caca25660dac18e2999b4fd8b1677b912a4bc6a1943eeac5d6eb882b9aae 550M 115G 582M legacy
docker/11f589c1af241fbb5ed62d1a4c0abab0d412100431e13048a47e43402e712266 75.5K 115G 155M legacy
docker/11fb2d38e33340679e98cbbabf0931c04c92a91bca3e129f590ac1b709fa0b6b-init 137K 115G 954M legacy
docker/121a4ec3dbd6fb2c229aa30bc19f33b13949e3ec650d3836cb4e8a3c2bf87c93 30.8M 115G 197M legacy
docker/12369ec72dc466014b519fa4b01e189f12081103c9ab95783ab0c75c4474f427 32K 115G 20.8M legacy
docker/12a70f4dd42f6b284a033f4c6b49b702d55168bd3eed81ae9c407fa3f2e37813-init 42K 115G 18.0M legacy
docker/12dd5e6e8876605a0034d55e9456c2b5a2bcff7594f36587f915f02033775dc1 2.84M 115G 2.84M legacy
docker/12m8jw958owy0ryhhsfxpbppo 122K 115G 546M legacy
docker/13037315f9620c064ef2c37eaa3596fb5fc7162048d93733f136400412f11e84 216M 115G 329M legacy
docker/131f6a656c912654b88203d2b6d628a4e29226cba41eea18fb5f8da34f585b26-init 56K 115G 56.7M legacy
docker/1322c1d20b0213a03748f421df89a444accbd5745aa205fd88d94b406bb009f8 49.7M 115G 79.7M legacy
docker/136f8d8134e9e8805dd6fb3ea5970d531ab7ad2e97d0663e8426cede071780ef 88.6M 115G 849M legacy
Ответ или решение
Причина, по которой Docker сталкивается с проблемой "zfs clone", связана с тем, как Docker интегрируется с файловой системой ZFS, и как это взаимодействие может приводить к затруднениям в работе, особенно при большом количестве данных. Давайте рассмотрим это подробнее, чтобы понять корень проблемы и как ее можно решить.
Теория
Файловая система ZFS известна своими мощными возможностями управления объемами данных, такими как снапшоты и клоны. Использование Docker вместе с ZFS обычно обеспечивает высокую производительность и эффективность за счет возможностей ZFS по управлению контейнерами как клонов снапшотов. Однако, если системы не настроены правильно или объем данных становится чрезмерно большим, могут возникать задержки или зависания, как в вашем случае.
ZFS создает клоны объектов данных, используя базовую архитекуру ведения истории снапшотов. Каждый раз, когда вы запускаете контейнер (создаете новый или запускаете существующий), Docker может создавать клон из своего базового образа, реальзующегося в виде файла ZFS. Если в вашей системе накапливается значительное количество таких клонов (как вы упомянули, около 1700), это может стать причиной задержек из-за высоких требований к ресурсу процессора и памяти для обработки такой нагрузки.
Кроме того, как указано в вашей конфигурации, команда zfs clone -p -o mountpoint=legacy используется для создания клонов. Если процессы создания клонов долго выполняются или тормозят из-за внутреннего конфликта ресурсов или состояния взаимоблокировки, то это может быть той самой причиной проблемы.
Пример
На практике, если /var/lib/docker размещено на ZFS, и используются образы и контейнеры в больших количествах без периодической очистки и оптимизации, накопление лишних снапшотов и клонов может запрашивать значительные ресурсы для управления этими объектами данных. Это может быть аналогично ситуации, когда на вашем сотоянии наблюдается блокировка "zfs clone".
Вот пример возможной организации данных и действий, которые могли бы привести к такой ситуации:
- Установка Docker с использованием ZFS для контейнеров.
- Запуск и остановка множества контейнеров без очистки и должного управления.
- Накопление большого количества ненужных или старых снапшотов.
Применение
Для решения и обхода этой проблемы существует несколько подходов:
-
Очистка ненужных данных. Хотя уже был использован
docker system prune -a, возможно, необходимо более глубокое удаление или управление образами и контейнерами через удаление старых клонов и снапшотов. -
Проверка зависимостей ZFS. Убедитесь, что ваша версия ZFS совместима с вашей версией Docker и Ubuntu. В вашем случае вы работаете на Ubuntu Server 24.04, что является довольно новой сборкой, и может потребоваться убедиться, что все обновления ZFS и Docker применены правильно.
-
Оптимизация ZFS. Обратите внимание на следующие настройки, которые могут быть полезны:
- Проверьте настройки ZFS, такие как
zfs_arc_max, чтобы оценить потребление памяти ZFS. - Оптимизируйте периодическое удаление снапшотов, чтобы избежать переполнения и перегрузки системы.
- Возможное использование другой файловой системы для /var/lib/docker, если на текущей системе ZFS проблема остается нерешенной.
- Проверьте настройки ZFS, такие как
-
Мониторинг и диагностика. Используйте инструменты мониторинга, такие как
zpool status, для получения информации о состоянии ZFS пула, и убеждение в отсутствии аппаратных или программных ошибок. -
Альтернативные решения. В случае если проблема сохраняется, стоит рассмотреть возможность использования другой системы COW (Copy-On-Write), чтобы обеспечить более стабильную работу. Например, перейти на overlay2, особенно если ZFS в вашем окружении показывает признаки нестабильности.
Применяя эти стратегии, вы сможете улучшить производительность Docker на ZFS и минимизировать риск остановов или замедлений. Однако, важно также помнить, что каждая ситуация уникальна, и часто эффективное решение заключается в сочетании нескольких методик подхода к оптимизации системных ресурсов и структуры данных.