Python в запущенный в контейнере работает медленнее натива?

Question

[mkone112]

Python запущенный в контейнере тормозит, разница с нативом от 10% до 20%.

Нативно:

git clone https://github.com/vprelovac/python-speed.git
cd python-speed
python3 bench.py

python-speed v1.3 using python v3.10.4
string/mem: 5542.03 ms
pi calc/math: 5804.19 ms
regex: 5761.4 ms
fibonnaci/stack:  4344.92 ms
multiprocess: 2502.46 ms

total:  23955.0 ms (lower is better)

В контейнере:

docker run -it python:3.10.4 bash
git clone https://github.com/vprelovac/python-speed.git
cd python-speed
python3 bench.py

python-speed v1.3 using python v3.10.4
string/mem: 7459.51 ms
pi calc/math: 5907.84 ms
regex: 6807.83 ms
fibonnaci/stack:  4113.53 ms
multiprocess: 2714.27 ms

total:  27002.99 ms (lower is better)

Я предположил, что дело в https://github.com/moby/moby/issues/41389, но добавление флагов `--privileged` или `--security-opt seccomp:unconfined` ни к чему не привело.

Куда можно копать чтобы решить проблему?

Kubuntu 22.04 LTS , ядро 6.1.28-060128-generic

Версия libseccomp: 2.5.3-2ubuntu2

Ядро: 6.1.28-060128-generic

Патчи от meltdown/spectre отключены mitigations=off

Comments

[ValdikSS]

Вы сравниваете скорость python, скомпилированным вашим дистрибутивом, и python, скомпилированным создателем пакета python на Debian Bullseye, со стандартными флагами компиляции.
https://github.com/docker-library/python/blob/mast...

chroot'нитесь в файловую систему вашего контейнера без docker и сравните различия в скорости между chroot-окружением и docker. Скорее всего, их не будет.

[ValdikSS]

https://github.com/docker-library/python/issues/825

[mkone112]

ValdikSS,

chroot'нитесь в файловую систему вашего контейнера без docker

Как?

https://github.com/docker-library/python/issues/825

Там вроде перечисляют теже флаги `security-opt seccomp:unconfined` и `--privileded`

[Александр Карабанов]

mkone112, не причём тут ни Docker ни capabilities - дело в самом Python

Answer 1

[Александр Карабанов]

Разница в бинарях - Python на хостовой машине собран без отладочной информации, а тот, который в образе python:3.10.4 собран с нею.

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

Можно пойти дальше и собрать Python из исходников самому, но самостоятельная сборка это такое себе развлечение (хотя с помощью pyenv делать это довольно просто), а выигрыш не такой уж и значительный - устанавливать бинарные пакеты сильно проще.

PS
Никогда не используй образы Alpine - там вместо glibc суррогат под названием musl. В прочем для статически слинкованных бинарей на Go использовать можно, но тогда уж выгоднее использовать scratch

Comments

[mkone112]

Можно пойти дальше и собрать Python из исходников самому

А можно от этого что-то выиграть?

[Александр Карабанов]

mkone112, можно добавить флагов оптимизации, собрать используя особенности конкретного проессора и так далее - это даст некоторый прирост производительности, но смысла в этом почти нет, так как велик шанс утратить стабильность и получить непереносимый бинарь. Иными словами оно того не стоит, разве что для общего развития имеет смысл.

[mkone112]

Александр Карабанов,

можно добавить флагов оптимизации, собрать используя особенности конкретного проессора и так далее

А где про это можно почитать?

[Александр Карабанов]

mkone112, например GCC optimization

[fenrir]

mkone112, в Python Developers Guide есть все инструкции для самостоятельной сборки, а флаги сборки есть в документации

Answer 2

[historydev]

Можешь попробовать минимальный образ.

Здесь говорят что alpine может замедлить конкретно пистон: https://pythonspeed.com/articles/alpine-docker-python/

Это скорее всего решит проблему: https://stackoverflow.com/questions/76130370/why-i...

Comments

[mkone112]

slim ничего не меняет, alpine вообще виснет на этом тесте.