Sé que esta pregunta se ha hecho de manera similar antes, pero mi pregunta es más específica y las existentes son antiguas. Entonces las cosas podrían haber cambiado mucho (pensando en instrucciones vectoriales, por ejemplo).
Dicho simplemente, tengo un módulo de Python que básicamente siempre necesito usar y mi código de Python se ejecuta mucho más lento (tiempos de ejecución dobles) en las máquinas virtuales (tipo 1 y 2). El módulo en sí es principalmente un contenedor/API en la biblioteca C, pero no de forma exclusiva.
Estoy tratando de averiguar si Python se ve afectado o solo el módulo. Entonces, ¿se sabe que Python sufre mucho cuando se ejecuta en una VM?
Respuesta1
A partir de tu pregunta no hay forma de saber si estás comparando manzanas con manzanas.
En un entorno de virtualización correctamente configurado y razonablemente cargado, espero que la mayoría de las cargas se ejecuten como máximo un porcentaje un poco más lento que en el sistema básico. Si su código es enormemente escalable y puede utilizar todos los recursos de hardware disponibles, espero que funcione significativamente peor en un entorno virtualizado, especialmente si los recursos son escasos. Si su código depende de un hardware acelerador específico, el impacto de la virtualización es específico de la implementación.
Respuesta2
No has demostrado nada, tienes toneladas de variables que no has aislado. Versión de Python, versión del sistema operativo, recursos de hardware, cuotas de recursos de VM, modelo de CPU, etc.
Perfile qué funciones en su código específicamente están tomando tiempo. Visualízalo congráficos de llamas.Muestreo de pila basado en PythonLa implementación sería buena, pero no sé qué tan bien captura las funciones de C. En ese caso, es posible que desee probar perfiladores basados en el sistema operativo (eBPF, xperf), que tienen mejor visibilidad de la biblioteca C y del sistema operativo.
Estudia en detalle qué funciones son lentas. Tenga una idea de lo que hace, obtenga el código fuente si es posible. Cuente las llamadas al sistema para medir lo que solicita al sistema operativo.
Encuentre el recurso limitante: CPU, memoria, disco, red. Mida esos recursos a nivel de host a través de herramientas de monitoreo del desempeño.
Compare los resultados en diferentes entornos, bare metal, diferentes tipos de VM y diferente hardware. No comprometa demasiado los recursos de sus hosts de VM, ni de la CPU y, definitivamente, tampoco de la RAM. Esto es injusto en comparación con un host dedicado.
Realmente, esta es una investigación de rendimiento general para descubrir cuál es el factor limitante en su entorno. El uso de Python simplemente puede cambiar el tiempo de ejecución del código para perfilar y optimizar.
Respuesta3
Lo más probable es que el código en cuestión realice MUCHOS cambios de contexto (y/o el hipervisor esté exacerbando el cambio de contexto al mover el núcleo virtual alrededor de núcleos físicos). El cambio de contexto puede ser hasta aproximadamente 100 veces más costoso en un hipervisor que en un sistema básico. Los errores de caché también pueden ser un factor importante, debido a que el hipervisor programa los núcleos virtuales en torno a diferentes núcleos físicos.
Para aliviar algunos de esos gastos generales, fije los núcleos virtuales a los núcleos físicos, exponga la topología de la CPU subyacente a la VM (sockets/núcleos/hilos), mantenga la VM completamente dentro de un único nodo NUMA y no le dé al invitado la información completa. conjunto de núcleos/subprocesos de CPU que tiene en el host si su código es sensible a la latencia de memoria/caché.
El rendimiento bajo un hipervisor para diversas cargas de trabajo puede ser dramáticamente peor que en un sistema básico.Los números son de hace años, pero vuelvo a probar estas cosas con bastante regularidad y las cosas no han cambiado mucho en la última década.