Я нахожу ограничение Docker? Мое приложение (couchdb) не запускается внутри контейнера докеров при > 1 миллионе папок [з ⇐ Linux

[Anonymous]

Я создаю Docker-контейнер, в котором размещается Couchdb 1.5.0 (по разным причинам мы не можем обновиться до более новой версии). Мы хотим перенести хост-систему на Ubuntu 24, сохранив при этом Couchdb в среде Ubuntu 16.
Couchdb — это файловая база данных, доступная только для добавления, поэтому каждый пользователь получает свой собственный файл базы данных. В нашей производственной базе данных 1 082 324 папки.
Когда я удаляю папки из папки базы данных Couchdb (привязка привязки в Docker Compose, а не том) примерно до 99 тысяч папок, все работает нормально (хотя запуск занимает около 2 минут). Наша предварительная настройка работает нормально, но она намного меньше.
В наших старых внутренних инструкциях по установке Couchdb говорится, что нужно увеличить обработчики файлов в /etc/default/limits.conf до 8092 (я установил их еще выше, но наша рабочая база данных имеет этот предел и работает нормально).
cat /proc/$(pgrep -f run.sh)/limits | grep "Max open files"

Max open files 1048576 1048576 files

Я установил это внутри контейнера и снаружи для процесса докера, поскольку это собственный порожденный дочерний процесс.

• Я повесил на процесс строку, что было очень неубедительно (у меня недостаточно знаний, чтобы ее прочитать, я просто скормил ее ChatGPT, который дал мне обычные бесполезные ответы)
• inotifywait не показывает никакой активности в папке, так же, как статистика iotop или docker
• Я вижу только небольшой всплеск оперативной памяти при запуске процесса, но затем снова падает. Не похоже, что его убивают, потому что процесс все еще работает. Я запустил его вручную внутри контейнера, используя:

/usr/bin/erl +Bd -noinput -os_mon start_memsup false start_cpu_sup false disk_space_check_interval 1 disk_almost_full_threshold 1 -sasl errlog_type error +K true +P 131072 +A 4 -env ERL_LIBS :/usr/lib/x86_64-linux-gnu/couchdb/erlang/lib -couch_ini /etc/couchdb/default.ini /etc/couchdb/local.ini -s couch

Конфигурация и версия определенно такие же, как и в нашей рабочей базе данных. У нас есть система резервного копирования, которая также представляет собой установку на «голое железо», которая запускается менее чем за секунду. Я могу оставить это работать на 8 часов или больше, но ничего не произойдет.
Наш новый сервер намного мощнее старого. У нас 60 ГБ оперативной памяти, так что это не должно быть проблемой. База данных находится на совершенно новых дисках nvme. Все на современном уровне.
К настоящему моменту я отключил все функции безопасности докера, настроил ограничения, разрешения правильные, проверил, попробовал тома докера, переключил хост-систему на cgroupsv2, а что нет. Вся установка докера, включая контейнеры, переносится на устройства nvme.
Вот мой файл компоновки докера:
services:
couchdb:
tty: true
hostname: couchdb-${COUCHDB_UUID}
image: couchdb-1.5.0
restart: unless-stopped
privileged: true
ulimits:
nofile:
soft: 1048576
hard: 1048576
deploy:
resources:
limits:
memory: 60G
security_opt:
- apparmor=unconfined
- seccomp=unconfined
cap_add:
- ALL
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost:5984/ || exit 1"]
interval: 30s
timeout: 5s
retries: 3
start_period: 10s
ports:
# We let the service listen on all interfaces, because if a VIP is added when making the slave the new master, it will be confusing otherwise
- 5984:5984
# This is for the prometheus exporter
- 9984:9984
build:
context: .
dockerfile: Dockerfile
environment:
TZ: Europe/Berlin
volumes:
- ./couchdb_database:/var/lib/couchdb/
- ./limits.conf:/etc/security/limits.conf
- ./local.ini:/etc/couchdb/local.ini
- ./99-nofile.conf:/etc/systemd/system.conf.d/99-nofile.conf
- ./strace.log:/var/log/strace.log
- ./build/run.sh:/run.sh
- ./couchdb.sh:/usr/bin/couchdb
- ./couchdb.log:/var/log/couchdb.log
- ./inotify.log:/var/log/inotify.log
- ./sysctl.conf:/etc/sysctl.conf