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

Как я уже говорил выше в своём посте, я пробовал использовать и встроенную флеш-память на устройстве, и внешние накопители. Причём внешние накопители у меня были разные — от USB-флешек до SSD и NVME-накопителей.

Дополнительная информация изнутри контейнеров. Я обновил 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%

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

Всё, что запускается внутри /container/shell, работает так, как и должно. Я могу попробовать запустить stress-ng --cpu 4 --aggressive в качестве entrypoint в контейнере, как делаю с strace, но исходя из всего, что я уже пробовал, скорее всего, программа даже не загрузит свой код достаточно, чтобы попытаться загрузить систему.

Возможно, проблема в диске, который ты используешь?

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

Либо минимальный воспроизводимый тестовый пример, который должен показывать тот же результат в любом месте. Нереально ожидать, что сторонние тестировщики будут разворачивать такие сложные вещи, как VictoriaMetrics, но если вы дадите что-то, что можно проверить за минуту без внешних зависимостей, на вашу проблему обратят внимание гораздо больше людей.