Mikrotik.moscow [тема: Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.]

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Sat, 01 Jun 2024 14:21:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Вчера получил свой ax^3, обновился до версии 7.15 и тоже столкнулся с этой проблемой. Единственный используемый контейнер — linuxserver/duckdns:latest, и он запускается целых 10 минут. Две переменные окружения (имя домена и токен), без смонтированных каталогов. Хранение данных — USB2 флешка (чтобы избежать помех USB3), которая, насколько я знаю, довольно быстрая. Это очень простая программа для DDNS. Было бы здорово, если кто-то попробует воспроизвести ситуацию.
01.06.2024 14:21:00, akabyshev.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Thu, 30 May 2024 15:01:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Либо минимальный воспроизводимый тестовый пример, который должен показывать тот же результат в любом месте. Нереально ожидать, что сторонние тестировщики будут разворачивать такие сложные вещи, как VictoriaMetrics, но если вы дадите что-то, что можно проверить за минуту без внешних зависимостей, на вашу проблему обратят внимание гораздо больше людей.
30.05.2024 15:01:00, tangent.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Thu, 30 May 2024 06:02:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Для справки: у меня работают контейнеры на RB5009 (iperf, PiHole) и AX3 (netinstall), и ни у одного из них нет проблем с производительностью. Оба устройства довольно часто получают тестовые сборки (сейчас 7.15rc5). Может, пора показать свою конфигурацию?
30.05.2024 06:02:00, holvoetn.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Thu, 30 May 2024 05:11:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Как я уже сказал, я пробовал это с несколькими образами разных приложений и получал одинаковый результат с одинаковым выводом из контейнеров. Я опубликовал вывод только одного примерного контейнера, потому что результаты были одинаковыми и у остальных контейнеров.
30.05.2024 05:11:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Thu, 30 May 2024 05:09:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Да, правильно. Я использовал victoriametrics/vmagent для контейнера, вывод которого я приводил выше. Также я собирал собственные образы (не для victoriametrics, а для других приложений) и сталкивался с той же проблемой: первый PID в контейнере, казалось, «затормаживался», но любые другие PID (например, если зайти в контейнер через shell и выполнить какие-то команды) работали без проблем с производительностью. Я даже пробовал сделать так, чтобы первым процессом в кастомных контейнерах был просто скрипт entrypoint, который потом запускает приложение, но процесс, запущенный из этого скрипта (когда он наконец-то медленно выполнял двухстрочный скрипт), тоже унаследовал эту задержку.
30.05.2024 05:09:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Wed, 29 May 2024 04:27:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Возможно, проблема в диске, который ты используешь?
29.05.2024 04:27:00, Amm0.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Wed, 29 May 2024 04:26:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Я знаю, что есть люди с контейнером iperf. Просто на форуме, кроме твоего сообщения, нет других отчетов. Обычно, если проблема массовая, разгорается буря обсуждений... Я верю, что ты действительно сталкиваешься с чем-то. Но тебе нужен один пример, один конкретный случай, который воспроизводит ту самую медлительность, которую ты видишь. Фраза «все контейнеры медленные… а в shell — нет» немного сбивает с толку.
29.05.2024 04:26:00, Amm0.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Wed, 29 May 2024 04:08:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Всё, что запускается внутри /container/shell, работает так, как и должно. Я могу попробовать запустить stress-ng --cpu 4 --aggressive в качестве entrypoint в контейнере, как делаю с strace, но исходя из всего, что я уже пробовал, скорее всего, программа даже не загрузит свой код достаточно, чтобы попытаться загрузить систему.
29.05.2024 04:08:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Wed, 29 May 2024 04:07:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
К вашему сведению, даже Pi-hole так делает, и я знаю, что по крайней мере десятки людей его используют.
29.05.2024 04:07:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Tue, 28 May 2024 18:42:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Попробуйте нагрузить систему, запустив stress-ng внутри контейнера (например, stress-ng --cpu 4 --aggressive). Загружает ли это все ядра процессора на 100% при мониторинге CPU через ROS /system/resource/monitor? Также можно попробовать запустить бенчмарк-скрипт yabs.sh внутри контейнера и поделиться результатом.
28.05.2024 18:42:00, optio.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Tue, 28 May 2024 17:32:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Я регулярно использую контейнер traefik на своём основном тестовом роутере, и не замечал никаких тормозов. Трафика там не так много, правда. Но контейнеры запускались быстро и работали во всех вариантах 7.15beta. Я понимаю, ты говоришь, что все контейнеры тормозят на всех платформах. Но, возможно, дело в каких-то конкретных контейнерах из определённого набора. RouterOS не поддерживает все «возможности» (–cap-add), поэтому, возможно, код выполняется медленнее в пользовательском режиме, потому что не имеет доступа к ядру для чего-то... не знаю. Но ты говоришь, что всё нормально работало в 7.13, а вот начиная с 7.14 и в бета/релиз-кандидатах всё стало сильно отличаться. Можешь проверить на более старой версии? Если там быстро — это как раз докажет, что баг есть.
28.05.2024 17:32:00, Amm0.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Tue, 28 May 2024 00:19:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Дополнительная информация изнутри контейнеров. Я обновил entrypoint и cmd, чтобы запускать strace как первый процесс, который стартует программу, чтобы зафиксировать трассировку активности и понять, ведёт ли себя приложение неправильно. Видно, что strace запустился успешно и пытается запустить программу.

/ # ps -ef
PID USER TIME COMMAND
1 root 0:00 strace -ffyo /etc/vmagent/strace.out /vmagent-prod -remoteWrite.url=http://xxxxxx:9009/api/v1/push -promscra
9 root 0:00 strace -ffyo /etc/vmagent/strace.out /vmagent-prod -remoteWrite.url=http://xxxxxx:9009/api/v1/push -promscra
10 root 0:00 ps -ef

Можно видеть, что он уже записал файл /etc/vmagent:

# ls -la /etc/vmagent/
total 20
drwxr-xr-x 2 root root 4096 May 28 00:04 .
drwxr-xr-x 20 root root 4096 May 27 23:36 ..
-rw-r--r-- 1 root root 10 May 27 23:36 .type
-rw-r--r-- 1 root root 476 May 27 23:43 prometheus.conf
-rw-r--r-- 1 root root 199 May 28 00:05 strace.out.11

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

/etc/vmagent # cat /etc/vmagent/strace.out.11
execve("/vmagent-prod", ["/vmagent-prod", "-remoteWrite.url=http://xxxxxx"..., "-promscrape.config=/etc/vmagent/"...], 0xfffffffffd50 /* 3 vars */) = 0
set_tid_address(0xeef210) = 11
brk(NULL) = 0xf3e000
brk(0xf40000) = 0xf40000
mmap(0xf3e000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf3e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff7ffd000

Спустя 10 минут… она сделала всего 10 вызовов, хотя к этому моменту должно было быть сотни системных вызовов:

execve("/vmagent-prod", ["/vmagent-prod", "-remoteWrite.url=http://xxxxxx"..., "-promscrape.config=/etc/vmagent/"...], 0xfffffffffd50 /* 3 vars */) = 0
set_tid_address(0xeef210) = 11
brk(NULL) = 0xf3e000
brk(0xf40000) = 0xf40000
mmap(0xf3e000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf3e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff7ffd000
munmap(0xfffff7ffd000, 4096) = 0
sched_getaffinity(0, 8192, [0 1 2 3]) = 8
openat(AT_FDCWD, "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff7fbe000
mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff7f9e000
mmap(NULL, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff7e9e000
mmap(NULL, 8388608, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff769e000
mmap(NULL, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffff369e000
mmap(NULL, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffd369e000
mmap(NULL, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffb369e000

Он будет продолжать вызывать системные вызовы с невероятно низкой скоростью часами и так и не сможет выполнить достаточное количество вызовов для полноценного запуска приложения. Такое ощущение, что ROS как будто бы намеренно ограничивает контейнер, хотя использование CPU и памяти не показывает проблем с ресурсами.

[admin@MikroTik] /system/resource> print
uptime: 38m56s
version: 7.14.3 (stable)
build-time: 2024-04-17 12:47:58
factory-software: 7.5
free-memory: 657.4MiB
total-memory: 928.0MiB
cpu: ARM64
cpu-count: 4
cpu-frequency: 1320MHz
cpu-load: 1%
free-hdd-space: 90.2MiB
total-hdd-space: 128.0MiB
write-sect-since-reboot: 2387
write-sect-total: 388926
bad-blocks: 0%
architecture-name: arm64
board-name: hAP ax^3
platform: MikroTik

[admin@MikroTik] /system/resource> cpu/print
Columns: CPU, LOAD, IRQ, DISK
# CPU LOAD IRQ DISK
0 cpu0 1% 0% 1%
1 cpu1 1% 0% 1%
2 cpu2 2% 1% 0%
3 cpu3 1% 0% 0%
28.05.2024 00:19:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Mon, 27 May 2024 22:17:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Отменяю свои слова, это касается не только версии 7.15. Я наблюдаю те же проблемы на 7.14.2 и на другом устройстве (hAP ax^3). Контейнеры запускаются и показывают статус «работает». Я могу зайти в них через shell и с помощью ps увидеть, что процессы действительно запущены. IP-адреса контейнеров доступны по пингу извне, и я могу успешно пинговать изнутри контейнера. Но netstat в контейнере показывает, что нет ни одного процесса, слушающего порты.

И так может продолжаться бесконечно, без какого-либо прогресса. Пока я не зайду в контейнер и не запущу точно ту же команду, которая уже запущена (согласно ps). И ТОЛЬКО ТЕПЕРЬ… приложение запускается, я могу получить к нему доступ по сети, netstat в контейнере показывает, что процесс слушает порты.

Однако вскоре после этого RouterOS убивает контейнер. Если после этого перезапустить контейнер, повторяется та же ситуация, и сервис внутри может так и не стать доступным.

Это воспроизводится на нескольких контейнерах, с разными образами контейнеров (разных приложений), на нескольких основных версиях ROS (тестировались 7.14 и 7.15), на разных файловых системах (локальная память и USB-накопитель).

Также стоит отметить, что в большинстве случаев ROS вообще не пишет никакие логи от контейнеров. Иногда, очень редко, в логах (info, containers, debug) появляется запись о запуске или остановке контейнера, но крайне нерегулярно, несмотря на то, что процесс запуска и остановки повторяется при тестировании.
27.05.2024 22:17:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Thu, 30 May 2024 05:08:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Как я уже говорил выше в своём посте, я пробовал использовать и встроенную флеш-память на устройстве, и внешние накопители. Причём внешние накопители у меня были разные — от USB-флешек до SSD и NVME-накопителей.
30.05.2024 05:08:00, autonomous.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Wed, 29 May 2024 12:59:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
Вы используете один из официальных образов контейнеров для этого или что-то, что вы собрали локально?
29.05.2024 12:59:00, tangent.

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2.

Fri, 10 May 2024 20:32:00 -0400

Ужасная производительность контейнеров с версии 7.14 до 7.15rc2. RouterOS в форуме RouterOS.
С тех пор как обновился до версии 7.14 и всех последующих версий, с которыми работал, мои контейнеры работают ужасно медленно. (см. обновления ниже, это происходит и в 7.14) Контейнер показывает, что запущен, но программы внутри становятся доступными только спустя 10 и более минут, иногда они вообще не запускаются, хотя контейнер в списке значится как «запущенный». Ответы программ внутри контейнера просто ужасно медленные. Пробовал на разных контейнерах — результат один и тот же. Пробовал использовать локальное flash-хранилище и SSD, подключенный через USB — без изменений. Полностью удалял все контейнеры и начинал заново — не помогает. Иногда перезагрузка роутера вроде бы решает проблему, но если контейнер перезапустить при работающем RouterOS, проблема сразу возвращается. Статистика CPU и памяти показывает, что контейнеры потребляют очень мало ресурсов, так что дело не в них. Кто-нибудь ещё сталкивался с таким? У меня RB5009UPr+S+.
10.05.2024 20:32:00, autonomous.