Eu sei que esta pergunta já foi feita de forma semelhante antes, mas minha pergunta é mais específica e as existentes são antigas. Então as coisas podem ter mudado muito (pensando nas instruções vetoriais, por exemplo).
Simplesmente disse que tenho um módulo python que basicamente sempre preciso usar e meu código python roda muito mais devagar (tempos de execução duplos) em VMs (tipo 1 e 2). O módulo em si é principalmente um wrapper/API na biblioteca C, mas não excursivamente.
Estou tentando descobrir se o próprio python foi afetado ou apenas o módulo. Então é sabido que o python sofre muito quando roda em uma VM?
Responder1
Não há como saber pela sua pergunta se você está comparando maçãs com maçãs.
Em um ambiente de virtualização adequadamente configurado e razoavelmente carregado, espero que a maioria das cargas seja executada no máximo alguns por cento mais lentamente do que em bare metal. Se o seu código for extremamente escalável e puder utilizar todos os recursos de hardware disponíveis, espero que ele tenha um desempenho significativamente pior em um ambiente virtualizado, especialmente se os recursos forem escassos. Se o seu código depender de hardware acelerador específico, o impacto da virtualização será específico da implementação.
Responder2
Você não provou nada, tem toneladas de variáveis que não isolou. Versão Python, versão do sistema operacional, recursos de hardware, cotas de recursos de VM, modelo de CPU e assim por diante.
Crie um perfil de quais funções em seu código especificamente estão demorando. Visualize-o comgráficos de chama.Amostragem de pilha baseada em Pythona implementação seria boa, mas não sei até que ponto isso captura funções C. Nesse caso, você pode tentar criadores de perfil baseados em sistema operacional (eBPF, xperf), que têm melhor visibilidade da biblioteca C e do sistema operacional.
Estude detalhadamente quais funções são lentas. Tenha uma ideia do que ele faz e obtenha o código-fonte, se possível. Contar chamadas do sistema para medir o que ele está solicitando do sistema operacional.
Encontre o recurso limitante: CPU, memória, disco, rede. Meça esses recursos no nível do host por meio de ferramentas de monitoramento de desempenho.
Compare os resultados em diferentes ambientes, bare metal, diferentes tipos de VMs, diferentes hardwares. Não sobrecarregue recursos em seus hosts VM, nem na CPU e, definitivamente, nem na RAM. Isso é injusto quando comparado a um host dedicado bare metal.
Na verdade, esta é uma investigação geral de desempenho para descobrir qual é o fator limitante em seu ambiente. Usar Python pode alterar o tempo de execução do código para criar perfil e otimizar.
Responder3
As chances são de que o código em questão faça MUITA troca de contexto (e/ou o hipervisor esteja exacerbando a troca de contexto ao mover o núcleo virtual em torno dos núcleos físicos). A troca de contexto pode ser até 100 vezes mais cara em um hipervisor do que em bare metal. As falhas de cache também podem ser um grande fator, devido ao hipervisor agendar núcleos virtuais em torno de diferentes núcleos físicos.
Para aliviar algumas dessas sobrecargas, fixe os núcleos virtuais em núcleos físicos, exponha a topologia da CPU subjacente à VM (soquetes/núcleos/threads), mantenha a VM inteiramente dentro de um único nó NUMA e não dê ao convidado o acesso completo conjunto de núcleos/threads de CPU que você possui no host se seu código for sensível à latência de cache/memória.
O desempenho em um hipervisor para diversas cargas de trabalho pode ser dramaticamente pior do que em bare metal.Os números são de anos atrás, mas eu testo essas coisas com razoável regularidade e as coisas não mudaram muito na última década.