ソフトウェア (ドライバーではなく、OS の一部ではなく、単なるアプリケーション) がほとんど仮想化環境で実行されることがわかっている場合、コードやコンパイラの設定を最適化するための戦略はありますか? または、すべきこととすべきでないことのガイドはありますか？
これはパフォーマンスが 0.0x% 向上するということではありませんが、パフォーマンスを大幅に向上させる単純なことや、単純に見えても仮想化環境では破滅的であることが知られていることがあるかもしれません。たとえば、カーネル ビルドで CONFIG_PARAVIRT を有効にするのは簡単で、パフォーマンスを大幅に向上させることができます。現在、アプリケーションに同様のものがある場合は探しています。
私の場合、それは C++ コードで、おそらく VMWare になりますが、できるだけ言語や製品にとらわれないように質問を続けたいと思います。そのような戦略があるのか、それとも時間の無駄なのか、仮想化の概念は仮想化についてあまり気にする必要がないということなのだろうか。
私があなたにできる唯一のアドバイスは、バグのあるバルーン ドライバーを探しながら mlock() / mlockall() を慎重に使用することです。
たとえば、Xen ゲストが 1GB で起動され、その後 512 MB に膨らんだ場合、準仮想化カーネルが実際にプロセスに約束したメモリ量 (つまり、Committed_AS) を特権ドメインが確認しなかったのは非常に一般的です。実際、Xen では、この値が Xenbus に配置されない限り、特権ホストはそのようなバルーンが何をするかわかりません。カーネルの構成方法によっては、これもKVMと一致すると思います..しかし、あなたの質問は、そのようなことについて何も知らないと仮定しています:)
そのため、単にページアウトできないものを保護し (慎重に、ただし慎重に)、常に「空が落ちてくる」シナリオを考慮してください。
同様に、 posix_fadvise() / posix_madvise() を使用して、PV カーネルにバッファリングが必要か不要かを伝えることは、常に良い考えです。
それを超えて、できることはほとんどありません..そもそもプロセスが仮想化を意識しないように設計された準仮想化カーネルとのみ話しているためです。
私は KVM を (まだ) あまり使用していませんが、将来さらに調査する予定です。しかし、私が最近書いたものの 90% は、準仮想化された Xen ゲストで実行するように特別に設計されています。少し Xen / C 中心で申し訳ありませんが、それが私の経験であり、pv_ops がメインラインにあります (すぐに xen-0 ops も) :)
良い質問です、ところで:)
編集：
私が「注意深く慎重に」と言ったとき、私は保守的な一歩上のことを意味しました. ほとんどの関数が必要とするジョブ構造をプログラムが割り当てる場合は、それをロックします。巨大なファイルを読み取るためにバッファーを割り当てる場合は、それらをロックしないでください..そして、必ず posix_fadvise() を呼び出して、一度だけアクセスするつもりであることをカーネルに知らせてください (その場合)。また、メモリ マップド ファイルの使用についてカーネルに通知するようにしてください。特に、それらが同時実行性を構成するのに役立つ場合は注意してください。
要するに、ホストカーネルがメモリを管理するのを助け、割り当てられた重要なブロックがダーティページングにスローされないようにし、割り当てたものすべてをロックすることでプログラムが何よりも重要であると想定しないでください:)
あいまいで申し訳ありません。私が思いついた最高のフレーズは「慎重に、しかし慎重に」でした。
私の唯一のアドバイスは、可能であればメモリと IO の使用を低く抑えることです。
VM の IO は、物理ハードウェアに比べてかなり遅いです。それを避けることができるなら、それを避けてください。
実際のハードウェアで遅いものは、システムが仮想化されるとさらに遅くなります。どれだけ遅くなるかは、使用されている仮想化テクノロジによって異なります。
特に、仮想環境外の世界との I/O を必要とするものはすべて避けてください。設定方法によっては、画面への描画、スワッピング、ディスクおよびネットワーク I/O が含まれます。これは、大まかに重要度の低い順です。
可能であれば、10 年前のコンピューターのために書いているふりをしてください。アプリケーションが 1999 年のデスクトップ PC またはラップトップで動作する場合は、問題なく動作するはずです。