Я знаю, что этот вопрос уже задавался похожим образом, но мой вопрос более конкретен, а существующие старые. Так что все могло сильно измениться (например, если подумать о векторных инструкциях).
Проще говоря, у меня есть модуль python, который мне в основном всегда нужно использовать, и мой код python работает намного медленнее (двойное время выполнения) на виртуальных машинах (тип 1 и 2). Сам модуль в основном представляет собой обертку/API на библиотеке C, но не экскурсивно.
Я пытаюсь выяснить, затронут ли сам python или только модуль. Так известно ли, что python сильно страдает при запуске в виртуальной машине?
решение1
Из вашего вопроса невозможно понять, сравниваете ли вы яблоки с яблоками.
В правильно настроенной и разумно загруженной среде виртуализации я ожидаю, что большинство нагрузок будут работать максимум на несколько процентов медленнее, чем на голом железе. Если ваш код масштабируется в огромных масштабах и может использовать все доступные аппаратные ресурсы, я ожидаю, что он будет работать значительно хуже в виртуализированной среде, особенно если ресурсов мало. Если ваш код зависит от конкретного ускорительного оборудования, влияние виртуализации зависит от реализации.
решение2
Вы ничего не доказали, у вас есть куча переменных, которые вы не изолировали. Версия Python, версия операционной системы, аппаратные ресурсы, квоты ресурсов виртуальной машины, модель ЦП и так далее.
Профиль, какие функции в вашем коде конкретно занимают время. Визуализируйте это с помощьюграфы пламени.Выборка стека на основе PythonРеализация была бы хороша, но я не знаю, насколько хорошо она охватывает функции C. В этом случае вы можете попробовать профайлеры на базе операционной системы (eBPF, xperf), которые лучше видят библиотеку C и ОС.
Подробно изучите, какие функции работают медленно. Получите представление о том, что она делает, получите исходный код, если возможно. Подсчитайте системные вызовы, чтобы измерить, что она запрашивает у операционной системы.
Найдите ограничивающий ресурс: ЦП, память, диск, сеть. Измерьте эти ресурсы на уровне хоста с помощью инструментов мониторинга производительности.
Сравните результаты в разных средах, bare metal, разных типах виртуальных машин, разном оборудовании. Не перегружайте ресурсы на хостах виртуальных машин, не CPU и уж точно не RAM. Это несправедливо по сравнению с bare metal выделенным хостом.
На самом деле, это общее исследование производительности, чтобы обнаружить, какой ограничивающий фактор находится в вашей среде. Использование Python может просто изменить время выполнения кода для профилирования и оптимизации.
решение3
Скорее всего, рассматриваемый код выполняет МНОГО переключений контекста (и/или гипервизор усугубляет переключение контекста, перемещая виртуальное ядро вокруг физических ядер). Переключение контекста может быть примерно в 100 раз дороже под гипервизором, чем на голом железе. Промахи кэша также могут быть существенным фактором из-за того, что гипервизор планирует виртуальные ядра вокруг разных физических ядер.
Чтобы снизить некоторые из этих издержек, прикрепите виртуальные ядра к физическим ядрам, откройте базовую топологию ЦП для виртуальной машины (сокеты/ядра/потоки), разместите виртуальную машину полностью в одном узле NUMA и не предоставляйте гостю полный набор ядер/потоков ЦП, имеющихся на хосте, если ваш код чувствителен к задержкам кэша/памяти.
Производительность под гипервизором для различных рабочих нагрузок может быть существенно ниже, чем на «голом железе».Приведенные там цифры получены много лет назад, но я достаточно регулярно перепроверяю эти данные, и за последнее десятилетие ситуация не сильно изменилась.