我知道這個問題以前曾被問過，但我的問題更具體，而且現有的問題已經過時了。所以事情可能已經發生了很大的變化（例如考慮向量指令）。
簡單地說，我有一個基本上總是需要使用的 python 模組，並且我的 python 程式碼在虛擬機器（類型 1 和 2）上運行速度要慢得多（雙倍運行時）。這個模組本身主要是 C 庫上的包裝器/API，但不是excursively。
我試圖弄清楚 python 本身是否受到影響，或者只是模組受到影響。那麼是否知道Python在VM中運行時會遭受很多痛苦呢？
答案1
從你的問題中無法知道你是否在進行同類比較。
在正確配置和合理加載的虛擬化環境中，我預計大多數負載的運行速度最多比裸機慢幾個百分點。如果您的程式碼具有大規模可擴展性並且可以利用所有可用的硬體資源，那麼我預計它在虛擬化環境中的效能會明顯較差，尤其是在資源稀缺的情況下。如果您的程式碼依賴特定的加速器硬件，則虛擬化的影響是特定於實現的。
答案2
你還沒有證明任何東西，你有大量的變數沒有被隔離。 Python版本、作業系統版本、硬體資源、VM資源配額、CPU型號等等。
分析程式碼中哪些函數具體佔用了時間。可視化它火焰圖。基於Python的堆疊採樣實作會很好，但我不知道捕獲 C 函數的效果如何。在這種情況下，您可能想嘗試基於作業系統的分析器（eBPF、xperf），它們可以更好地了解 C 庫和作業系統。
詳細研究哪些函數速度慢。了解它的作用，如果可能的話獲取原始碼。對系統呼叫進行計數以衡量它對作業系統的請求。
找到限制資源：CPU、記憶體、磁碟、網路。透過效能監控工具在主機層級測量這些資源。
比較不同環境、裸機、不同類型的虛擬機器、不同硬體的結果。不要過度使用虛擬機器主機上的資源，不要過度使用 CPU 資源，也不要過度使用 RAM 資源。與裸機專用主機相比，這是不公平的。
實際上，這是一項一般性能調查，旨在發現您的環境中的限制因素。使用 Python 可能會改變程式碼運行時以進行分析和最佳化。
答案3
有問題的程式碼很可能會進行大量上下文切換（和/或虛擬機器管理程式透過在實體核心周圍移動虛擬核心來加劇上下文切換）。在虛擬機器管理程式下，上下文切換的成本可能比在裸機上高出約 100 倍。由於管理程式圍繞著不同的實體核心調度虛擬核心，因此快取未命中也可能是重要因素。
為了減輕其中一些開銷，請將虛擬核心固定到實體核心，將底層 CPU 拓撲公開給 VM（套接字/核心/執行緒），將 VM 完全保留在單一 NUMA 節點內，並且不要為來賓提供完整的如果您的程式碼對快取/記憶體延遲敏感，則主機上擁有的CPU 核心/執行緒集。
各種工作負載在虛擬機器管理程式下的效能可能比裸機上的效能差得多。這些數字是幾年前的，但我定期重新測試這些東西，並且在過去十年中情況沒有太大變化。