Вопрос или проблема
На машине Photon OS в VMware ESXi:
docker run debian:jessie apt-get update
Процесс apt-get update занимает несколько часов и использует около 100% CPU, даже с пустым /etc/apt/sources.list.
С debian:stretch команда apt-get update выполняется как ожидается.
Что могло произойти? Где искать решение этой проблемы?
Вот способ для отладки.
Сначала запустите контейнер без apt-get update и найдите идентификатор процесса bash на хосте:
host$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1da12f0b5797 debian:jessie "bash" 2 minutes ago Up 2 minutes nifty_mayer
host$ docker top nifty_mayer
UID PID PPID C STIME TTY TIME CMD
root 1273642 1273622 0 21:16 pts/0 00:00:00 bash
Как только вы получите PID bash (в моем примере: 1273642), вы сможете на хосте использовать strace для этого процесса. Убедитесь, что отслеживаете дочерние процессы (с флагом -f) и сохраняете все логи в файл (с флагом -o /tmp/strace.log), затем запустите команду apt-get update в вашем контейнере. Подождите несколько секунд и просто остановите apt-get:
host$ strace -o /tmp/strace.log -fp 1273642
strace: Process 1273642 attached
strace: Process 1274684 attached
strace: Process 1274685 attached
^Cstrace: Process 1273642 detached
Проверьте /tmp/strace.log. В моем случае, вот пример того, что я увидел:
$ cat /tmp/strace.log
[... snip ...]
1274685 getrlimit(RLIMIT_NOFILE, {rlim_cur=1073741816, rlim_max=1073741816}) = 0
1274685 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
1274685 getrlimit(RLIMIT_NOFILE, {rlim_cur=1073741816, rlim_max=1073741816}) = 0
1274685 fcntl(4, F_SETFD, FD_CLOEXEC) = 0
1274685 getrlimit(RLIMIT_NOFILE, {rlim_cur=1073741816, rlim_max=1073741816}) = 0
1274685 fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[... snip ...]
1274685 getrlimit(RLIMIT_NOFILE, {rlim_cur=1073741816, rlim_max=1073741816}) = 0
1274685 fcntl(108272, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
1274685 getrlimit(RLIMIT_NOFILE, {rlim_cur=1073741816, rlim_max=1073741816}) = 0
1274685 fcntl(108273, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
и снова, и снова, и снова. Если хорошо присмотреться, идентификатор файлового дескриптора в функции fcntl просто не останавливается.
Затем я вспомнил, что в то время (jessie 10 лет!), лимиты файлов были ниже! Поэтому я проверил лимиты в контейнере:
root@1da12f0b5797:/# cat /proc/self/limits | grep file
Max file size unlimited unlimited bytes
Max core file size unlimited unlimited bytes
Max open files 1073741816 1073741816 files
Max file locks unlimited unlimited lock
Максимальное количество открытых файлов в контейнере составляет 1073741816, что очень много!
Поэтому я уменьшил его, используя ulimit -n 4096, все еще в контейнере, а затем снова запустил apt-get update:
root@1da12f0b5797:/# ulimit -n 4096
root@1da12f0b5797:/# apt-get update
Ign http://deb.debian.org jessie InRelease
Ign http://deb.debian.org jessie-updates InRelease
Ign http://deb.debian.org jessie Release.gpg
Ign http://security.debian.org jessie/updates InRelease
Ign http://deb.debian.org jessie-updates Release.gpg
И это сработало!
Коротко: Современный лимит открытых файлов в контейнере Docker гораздо выше, чем значения в те времена, и старое ПО, такое как этот 10-летний apt-get, не обрабатывает новые лимиты должным образом. Установка лимита на меньшее значение исправит проблему.
Ответ или решение
В виртуальной среде VMware ESXi, на системе Photon OS, пользователь столкнулся с проблемой, когда команда apt-get update в контейнере на основе образа debian:jessie потребляет около 100% процессорных ресурсов и выполняется на протяжении нескольких часов. Для решения этого вопроса важно глубже разобраться в основном вопросе, расположить его в контексте и рассмотреть возможные подходы к решению проблемы.
Теория
Первоначально стоит отметить, что Debian Jessie — это очень старая версия дистрибутива, выпущенная в апреле 2015 года. Она базируется на технологиях и программных решениях, которые на момент сегодняшнего дня могут быть не оптимизированы для работы в современных условиях, особенно в виртуализированных средах и контейнерах.
Одной из причин высокой загрузки процессора может быть использование устаревшего ПО. Современные контейнерные технологии и операционные системы, такие как PhotonOS, настроены на поддержку высоких стандартов безопасности и производительности. Когда старое программное обеспечение сталкивается с новыми системными ограничениями или возможностями, такими как лимиты на количество открытых файлов, оно может функционировать некорректно или неэффективно.
Пример
Чтобы диагностировать проблему, можно использовать различные системные утилиты. Один из методов — это использование strace, инструмента для отслеживания системных вызовов и сигналов. Запустив strace для отслеживания процесса apt-get update, вы можете увидеть повторяющиеся вызовы к системным ресурсам, включая попытки установки флагов закрытия дескрипторов файлов (FD_CLOEXEC) на очень большое количество открытых файлов. Это указывает на то, что операционная система назначает слишком большой лимит на количество открытых файлов, что ведёт к бесконечному циклу попыток проверок, которые заканчиваются ошибками "EBADF (Bad file descriptor)".
Эта проблема указывает на несоответствие между возможностями старого программного обеспечения и современными установками операционной среды. В старых версиях ОС или приложения лимиты на количество файлов обычно были намного меньше, и старые версии ПО не были готовы к новому высокому лимиту, установленному по умолчанию в контейнерной среде.
Применение
Решение проблемы стало возможным за счет снижения лимита открытых файлов на уровне контейнера. Команда ulimit позволяет вручную устанавливать эти лимиты. Например, упростив лимит до 4096 файлов, вы можете привести его в соответствие с ожиданиями старого ПО и обойти ошибку. Это позволяет apt-get update выполняться как ожидается, без зацикливания и чрезмерной нагрузки на процессор.
Кроме того, если использование Jessie обусловлено спецификой приложений, однако существует возможность обновления или миграции на более свежую версию (например, Stretch или даже более новые версии Debian), это может решить не только текущую проблему, но и многие другие потенциальные вопросы касающиеся безопасности и совместимости.
Заключение
Проблема, с которой вы столкнулись при использовании контейнера на основе debian:jessie на PhotonOS, служит важным напоминанием о том, что эволюция технологий требует не только добавления новых возможностей, но и учета совместимости старого ПО. Устаревшее ПО может неэффективно взаимодействовать с новыми технологиями без соответствующей корректировки параметров или обновления.
Решение этой проблемы путем настройки лимитов на количество открытых файлов — это временная мера. Для длительного использования необходимо рассмотреть переход на более новые версии операционных систем или программного обеспечения. Это не только устраняет текущие проблемы, но и значительно повышает уровень безопасности и эффективности вашего программного окружения.