仮想環境でのパフォーマンスへの執着またはプロファイリングの経験

率直に言って、ほとんどの開発者にとって非効率的なアプリケーションは不快感を引き起こします。 生産性を追求することは、本質的にほとんどスポーツであり、直接的な義務とは関係ありません。 私たちの多くの生活のように、ハブには、 さまざまな種類の非効率性に対する勝利の印象的な例がたくさんあります。 一般的に、優れた開発者はツールとプロファイリング手法に精通しています。 同じ記事で、Parallels Desktop 9 for MacおよびVMWare Fusion 5の仮想環境でのプロファイリングプロセスについて検討したいと思います。カットの下で、テストケースを待って、結果報告とハイパーバイザーの内部を最も残酷な形で。

仮想マシン内でプロファイラーを実行する必要があるのは誰ですか？

これは、この記事を読むときに最初に生じる質問です。 もちろん、シンプルなデバイスの助けを借りて、白パン（または黒パン）をトロリーバスに変えることができますが、実際には、仮想マシン内でプロファイリングを実行する必要があるのは誰ですか？ Macの幸せな所有者を思い出す時が来ました。彼らはWindowsまたはLinuxでの開発に多くのサービスを負っています。 もちろん、この場合、Mac OSは開発者の妨げにはなりません。VMWareFusionはマシン上にあり、Visual StudioはWindowsを備えた仮想マシン内にあるため、原則として開発が進行中であり、問​​題はありません。 アプリケーションプロファイリングの問題が発生するまで正確に。 Intel VTune Amplifierプロファイラ（たとえば、その1つ）によって収集されたデータに基づいた最適化に関するIntelの一連の記事に精通していると思います。そうでない場合は、今がその時です。 したがって、仮想マシン内にインストールされたVTune'omで武装し、プロファイリングに進みます。

仮想マシンでのプロファイリング

そのため、VTune Amplifierは仮想マシンにインストールされており、メモリを操作する最適性についてコンポーネントを分析することが決定されました。 分析が開始され、出来上がり：







結果なし。 その理由は、プロファイラーがその作業において、パフォーマンスモニタリングユニットとも呼ばれるハードウェアパフォーマンスカウンターのセットに依存しているためです。 各カウンタは、発生するたびに1つずつ増加するプロセッサイベント（プロセッサティックやキャッシュミスなど）に対して構成できます。 ソフトウェアインストルメンテーションと比較して、カウンタを使用してパフォーマンスインジケータを収集する独自の機能は、情報の完全性です。 多くの場合、実行可能コードだけでなく、たとえば頻繁なキャッシュミスを引き起こすコードもあります。 カウンタの値は継続的なポーリングによって認識できます。または、カウンタが特定のしきい値を超えたときに割り込みの生成を構成できます。 後者はプロファイラーの間でより一般的であり、単純化された作業スキームは次のようになります（図では、シングルコアプロセッサ上で動作し、プロファイラーが実行された最初の瞬間）。







カウンターオーバーフローで割り込みを受信すると、カウンターがインストールされてから0xFFイベントが発生したことがわかります。 その後、中断が発生したプロファイルされたアプリケーションの命令ポインターを掘り下げ、このIP自体が指す命令が0xFFイベントを引き起こしたと考えています。 そのため、統計を収集します。



浮気！ イベントがこの単一の命令だけでなく、2つの割り込みの間に実行されているブロック全体によって引き起こされたという事実は、注意深い読者の視線から逃れませんでした。 それでも、プロファイリングの結果は2つの主な理由で関連性を失うことはありません：2つの中断の間のイベントの数は十分な統計を取得するために十分に小さく選択され、結果は常にサンプルを増やすことで改善できます（より長いプロファイル-より正確には、結果）。 さらに、正確なイベントベースのサンプリングテクノロジがあり、これにより、いくつかのイベントに関する正確な統計を収集できます。



仮想マシン内のカウンターにアクセスすることはできません。明らかに、それらへのアクセスはエミュレートする必要があります（直接アクセスする場合、ゲストとホストのオペレーティングシステムは互いのデータを粉砕し、プロファイリングは機能しません）。 上記のエラーを受け取ったので、PMUはVMWare Fusionで仮想化されていません。 記事を終了することは可能ですが、...

VMWare Fusion 5の仮想化PMU

... VMWareFusion 5の幸せな所有者であれば、CPU設定で[CPUパフォーマンスカウンターの仮想化]ボックスをオンにできます。その後、プロファイラーはエミュレートされたパフォーマンスカウンターに依存して仮想マシン内で動作できます。



VM内のプロファイラーを使用して分析されるコンポーネントを検討します。 これは、次を表します。tSharedDataタイプのデータ構造。2つのストリームが共同でいくつかの操作を実行します。 2つのセマフォが同期に使用され、スレッドは共有データに順番に書き込みます。 同時に、3番目のスレッドが機能し、タイムスタンプカウンター値を読み取り、上記の構造に渡します。



2つのワーカースレッドのコード（nThreadNumはスレッド番号を定義します）：

DWORD WINAPI Thread(LPVOID lpParameter) { tThreadParam* pParams = (tThreadParam*)lpParameter; tSharedData* pData = pParams->pSharedData; while( pData->nIsWorking ) { if( pParams->nThreadNum == 1 ) { // First Thread pData->nLastThread = nCurrent; ReleaseSemaphore( pData->hSecondThreadSemaphore,1,NULL ); WaitForSingleObject( pData->hFirstThreadSemaphore, INFINITE ); }else{ //Second thread WaitForSingleObject( pData->hSecondThreadSemaphore, INFINITE ); pData->nLastThread = nCurrent; ReleaseSemaphore( pData->hFirstThreadSemaphore,1,NULL ); } } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サードストリームコード：

 DWORD WINAPI TimeThread(LPVOID lpParameter) { tSharedData* pData = (tSharedData*)lpParameter; while( pData->nIsWorkingCacheAligned ) //  ,          { //         pData->nCurrentTime = __rdtsc(); } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的にはかなり合成的な例ですが、仮想化環境でのプロファイリング中に発生する影響を明確に見ることができます。 20秒間分析すると、次の結果が得られます。







この表の2番目の列は、最初の列から関数の実行に費やされたプロセッサティックの数です。 ただし、次の2つの列に関心があります：MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT（M）-LLC（M）で（HIT）に変更された（以降、キャッシュミスはミスと呼ばれる）ロード（LOAD）データ（MEM）の実行（RETIRED）操作（OUPS）の数最初の2レベルのキャッシュ）。 そして、次の結果が表示されます。両方のスレッドが、ほぼ同じレベルで、最後のレベルの異なるコアのキャッシュを同期するプロセスを元気にトリガーし、パフォーマンスの問題を引き起こします。 原則として、結果は予想されます。3つのスレッドすべてが常に共有メモリにアクセスするため、データが正しくアライメントされていなければ、キャッシュの同期は避けられません。 深呼吸をして、最適化を続行するだけです。 それでも、仮想化環境でプロファイリングを実行しましたが、VMware Workstationが実行されている実際のマシン上でこのコードを既に調べて、結果を非常に確認できます。 そして結果...







...劇的に異なります。 ご覧のように、TSC値を読み取るストリームは、最初の2つのストリームと比較して、LLCデータのダウンロード数（修正されたものと修正されていないものの両方）を引き起こしました。 そのため、仮想マシン内で、紛らわしいデータを測定しました。 論理的な疑問が生じます：

PMU仮想化の何が問題になっていますか？

胸にもう少し空気を入れてください：この質問に答えるには、仮想マシン、特にIntel Virtualization TechnologyまたはVT-xを例として使用するハードウェア支援仮想化を使用する仮想マシンの操作の詳細に少し突入する必要があります。 この技術は、別のプロセッサモード-非ルートモードを追加します。 このモードで作業する場合、ハードウェア/システムリソース（ページ変換や割り込みテーブルなど）にアクセスすると、ゼロリングで「通常」のルートモードで実行される特別にインストールされたハンドラーに切り替わります。 このハンドラーを含む仮想マシンコンポーネントは、通常、仮想マシンモニターと呼ばれます。 コツは、VT-xテクノロジーを使用すると、ゲストシステムにリソースへの直接アクセスを許可するか、このアクセスをエミュレートするかを構成できることです。 たとえば、ゲストに実際のタイムスタンプカウンターを読み取らせますが、ページ変換のテーブルを掘り下げて、自分の影（シャドウ）を取得させないようにします。







したがって、PMU仮想化は基本的に、（ネイティブ（ホスト）OSのコンテキストを慎重に保存することにより）エミュレートするか、ゲストに完全に使用するために提供する印象的な数のカウンターの仮想化です。 最初のコードが多くの同じタイプのコードであり、プライベートルート/非ルートスイッチの非効率性（カウンターへの呼び出しごとにVMモニターが介入する）を掛け合わせることを考慮すると、仮想マシン開発者の選択は明らかです-ゲストがカウンターを自由に所有できるようにします。 そのため、彼らは最初にKVMでそれを行いましたが、ゲストTCPスタックのプロファイリングでは、機器を操作する時間が予想外に貧弱でした。 作業はモニターで行われ、プロファイルされたゲストの外で、ハードウェアにアクセスできませんでした。 そして、彼らの頭に明るいアイデアが浮かびました：モニターで発生したイベントも考慮に入れるとどうなりますか？ すぐに言ってやった。 現在、機器の運用はますます重くなっています。



しかし！



同時に、重み付けは、機器からのオーバーヘッドを考慮せずに、仮想化からの追加の負荷を考慮することによって引き起こされます。これは一般に、機器からの負荷とはあまり相関しません。 そのため、プロファイリングの結果が「妥当」に見える場合もありますが、現実からさらに離れていることが判明しました。 開発者の考えの動きについてはこちらをご覧ください 。



VMWare Fusion 5の開発者は、PMU仮想化に関する同様の質問に苦しみ、仮想化の概念をわずかに変更しました：すべてのイベントは「推測的でない」もの（実行された命令の数、ブランチの数、および「決定的」な性質を持つその他のメトリックなど）に分割されました：条件付き遷移-それらの多くが存在します）、および「投機的」遷移（キャッシュミスや誤って予測された分岐など）。 この場合、「投機的」イベントはハイパーバイザーの負荷を考慮して計算され、「非投機的」イベントは計算せずに計算されました（ ここで概念のより完全な説明）。 このようなロジックを理解することは難しくありません：機能コードに20の命令しかない場合、測定値が220を示す場合（仮想マシンモニターの作業が考慮されているという事実により）、推測することは難しくないため、そのような結果は混乱する可能性があります。 しかし、同時に、「投機的な」メトリックを測定しながら、上記で見たように、最適化中に頼るべきではない測定結果に対応できます。



これで、結果の違いがどこから生じるのかという質問に答えることができます。 時間を減算する関数は、エミュレートされたRDTSC命令を呼び出しますが、これは困難な作業ロジックを備えています（仮想マシンでの時間管理は、一般的にハイパーバイザー開発者にとって非常に困難な課題です）。 したがって、大量のキャッシュミス：RDTSC呼び出しで予想よりも多くの作業が行われています。

Parallels Desktop 9

もちろん、Parallels Desktop 9仮想マシンがゲストシステムからPMUにアクセスする機能を追加した場合、ハイパーバイザーの世界への没入は不完全になりますが、仮想化へのアプローチは少し異なります。イベントはゲストシステムのコンテキスト-測定結果に対するモニターの影響はすべて最小限に抑えられます。 この仮想マシン内でプロファイリングを試し、結果を比較してみましょう。







ご覧のとおり、結果はVMWareFusionよりも実際の機器の結果とより相関しています。 （時間を減算するスレッドにより、キャッシュミスがわずかに発生します）。 各ストリームで発生したイベントの数の間の関係の性質は維持されます。 仮想マシンのTimeThreadでキャッチされたゼロのキャッシュミスを混同する可能性がありますが、これはキャッシュミスが2000のオーダーで発生したことを意味するだけです-これはキャッシュミスカウンターをトリガーするためのしきい値です。 しかし、全体的に、特徴的な効果を観察し、将来、見つかった値に基づいて最適化を実行できます。



それでも、重要な疑問が残ります。それで、仮想化された操作に関連する負荷の一部が統計から外れているという事実はどうでしょうか？ もちろん、これは不快な効果ですが、次のことは注目に値します。99％の時間、モニターの介入なしに仮想マシンが動作します。つまり、一部の統計情報の損失はほとんど目に見えません。 しかし、主なことは、このアプローチはFuisonの場合よりも予測しやすいことです：コードに多くの効果が見つかった場合、再現できない効果を検出できるVMWare仮想マシンとは対照的に、それらは実際のハードウェアに表示されます実機で。

まとめ

ここまで記事を読んだ人は誰でも真に強い精神を持っています。 議論の外にあるのは、仮想環境でプロファイリングを試みるときに生じる他の多くの効果ですが、この記事の目的は、異なる環境でのプロファイリングの重要な違いを説明することであり、パフォーマンス測定の結果を解釈する際にどの問題を回避できるかを知ることです。 要約すると：



-穴あき抽象化の法則は依然として関連しており、仮想環境で作業する場合は二重に注目する価値があります。

-仮想化環境でのプロファイリングがパフォーマンスを分析する唯一のアプローチである場合、注意が必要です-時間と機器の操作により、ハードウェア効果の効果を測定する際に結果に重大なアーティファクトが生じる可能性があります。

-一般に、仮想マシンでは、アプリケーションを最適化できる指標に基づいて指標を収集できます。



ご清聴ありがとうございました！