偉大なSkype for Businessの記憶の謎

• 適用対象:

  Skype for Business

この記事は、エスカレーション エンジニアSkype for Business Kenn Guilstorf によって書かれました。

エスカレーション エンジニアとして、より多くの "persnickety" Skype for Business問題を顧客に支援します。 最近、私は「パフォーマンスベース」であるかなり多くのケースを受け取りました。基本的に、Skype for Businessが遅いか遅い、アプリケーションの共有を許可しない、または単にメモリを使い過ぎているという苦情。 多くの場合、これらのケースを調査すると、ユーザーは何週間も実行Skype for Businessし、時間の経過と同時に、パフォーマンスに影響を与えるまでメモリが機能しながっていることを示しています。 Skype を長時間実行させると、自分でも気付きました。 では、Skype は何をしていて、なぜそれほど多くのメモリを保持しているのでしょうか? (これは少しヒントです:これは正常であり、設計上です。何も間違っていない - すべてのネイティブ プログラムがこれに実行されます。)

どのくらいのメモリを噛むことができますか?

問題を解決するための最初の手順は問題を理解することです。問題を理解するための最初の手順は、問題を定義することです。 これは、聞こえるほど簡単ではありません。

Skype for Business (SfB) が最初に開始されると、メモリ使用量は非常に小さくなります (100 MB を小さくカウントできる場合)。 これは、タスク マネージャーなどの任意の数のツールで発生することがわかります。

図 1: だまされない: Lync.exe は SfB (32 ビット バージョン) のプロセス名です

時間の経過とともに、プロセスで使用されるメモリの量が増加します。 どの程度大きくなるかは、Skype の使用量、使用対象などによって決まります。 たとえば、約 24 時間後に同じクライアントを次に示します。

図 2: 同じ SfB 24 時間後

そのため、Skype は 24 時間で約 32 MB を消費しました。 それほど多くはありません。 Skypeは24時間アイドル状態だったことを説明するまではそうではありません。 基本的に、私はコンピュータでSkype for Businessを開始し、ロックを解除し、約24時間待ってからロックを解除しました。 特に会議に参加した場合、それらの会議でアプリ共有やデスクトップ共有を使用したり、IM を使用したりした場合は、料金がはるかに高くなります。 私は、Skype for Businessメモリ使用量が1日で300〜500 MBに増加したケースを見てきました。 特にメモリ制約の多い 32 ビット クライアントでは、1 週間以上の使用後に状況が大きくなる可能性があります。

メモリを表示する

メモリをプロファイリングできるツールは多数あります。 最も一般的な (少なくとも Microsoft) の 1 つは、 VMMap v3.26 で使用できる SysInternals ツール VMMap です。 これを使用してプロセス メモリを確認し、Skype for Business メモリをプロファイリングできるかどうかを確認できます。

VMMap をダウンロードしたら、それを実行します。 開始すると、プロセス一覧が開き、確認するプロセスを選択できます。 [lync.exe] を選択し、[OK] をクリックします。

図 3: 起動時の VMMap

次に、選択した実行可能ファイルの現在のメモリ プロファイルの複数色の表現であるグラフィック (この場合は Lync.exe) が表示されます。

図 4: 最近開始した Lync.exe の VMMap の開始

ここには多くの情報があり、それを説明すると、それ自体の1つ以上のブログ投稿がいっぱいになります。 興味がある場合は、それを説明するのに役立ついくつかの素晴らしい本やオンライン記事があります。 (個人的には、Jeffrey Richterの「Advanced Windows」をお勧めします。現在は印刷されませんが、メモリのしくみを説明する上で優れています。使用済みのコピーは、お気に入りの本屋で見つけることができます。

ご覧のように、 タスク マネージャー に表示されるメモリは VMMap のどのカテゴリとも一致しません。 タスク マネージャー は、より一般化された表現です。正確であり、すべてをカウントするわけではありません。 VMMap の方がはるかに包括的です。

24 時間待機期間が経過した後の Skype インスタンスを次に示します。

図 5: 24 時間後の Skype 用 VMMap

メモリはどこにありますか?

個々のカテゴリを比較すると、実際には何も並び合わない。 実際にメモリを消費している内容を見つけることは困難です。これは、オブジェクトとメモリ要求が行われ解放されるとメモリのカテゴリが変動し、メモリが予約され、さまざまなオブジェクトを格納するためにコミットされるためです。 "知識のカーネル" (このブログの目的では、とにかく) は "無料" カテゴリです。 この例では、"空き" メモリは、Lync 実行可能ファイル用に "予約済み" のすべての空き領域です。 ただし、特定の種類の "コミット済み" メモリのみが タスク マネージャーに表示されます。 予約済みメモリは使用されていないためカウントされません。

では、メモリはどこにありますか? メモリが失われないため、特定が困難になります。 一般的な信念とは対照的に、Skypeチームはデスクトップメモリメーカーによって補助金を受けなかった。 お客様にシステムやメモリをアップグレードしてもらうための悪質なプロットはありません。 これは、計画的な陳腐化の場合でもありません。 真実は説明するのがもう少し難しいです。

少しバックトラックして、物事をより明確にしましょう。 Skype for Business クライアントを初めて起動すると、比較的小さなメモリ フットプリント (通常は 100 MB など) があります。これは、連絡先の数とその他のオーバーヘッドに応じて異なります (上記のデータで明確に確認できます)。 数日後、このフットプリントは数十万バイトから数メガバイトに増加することがわかります。 特定の状況では、これは問題になる可能性がありますが、必ずしもSkype for Business自体の問題ではありません。 むしろ、Windows プログラミング パラダイムの効果であり、メモリをネイティブに処理する方法です。

Windows プログラミング

私はここでWindowsメモリの単純なビューを与えるつもりです。 Windows メモリは、割り当てと割り当て解除と呼ばれる高価な (コンピューター のサイクルとリソースの観点から) 手順によって処理されます。 プログラムにメモリが必要な場合は、Windows に割り当てるように求められます。 メモリが不足している場合、プログラムは Windows に割り当てを解除するように求めます。 内部的には、Windows はいくつかのプロセスを経てメモリ要求を管理します。

要求が行われると、Windows は、既にプロセスにコミットされているが、プロセスが使用していないメモリをチェックします。 Windows は、使用するのに十分な大きさのメモリ ブロックがあるかどうかを確認しています。 ある場合、システムはそれを使用し、その陽気な方法で進みます。 存在しない場合は、予約済みメモリをチェックします。 予約済みメモリのブロックが十分に大きい場合は、("pages" と呼ばれるオペレーティング システム定義のチャンクで) コミットし、その中に変数を格納します。 これでメモリがコミットされ、実行可能ファイルのメモリ 占有領域が拡大されました。

要求を処理するのに十分な予約済みメモリがない場合はどうなりますか? オペレーティング システムは、可能であれば、より多くのメモリを予約しようとします。 ここでは、32 ビット アーキテクチャと 64 ビット アーキテクチャの違いが生じます。 32 ビット プロセスでは、最大 4 GB のメモリのみを使用できます。 これは、32 ビット レジスタがアドレス指定できる最大量は 4 GB であるためです。 (ビットは 1 または 0 – バイナリのみを保持できます。したがって、32 ビットは、2³² が許可されている最も高いアドレスであることを意味します)。 32 ビット アーキテクチャにより、そのメモリの約 2 GB のみがプロセス自体に割り当てられ、残りの部分はオペレーティング システムによって使用され、共通 DLL のマップ、一般的なカーネル モード オブジェクトの処理などが行われます。 64 ビット システムでは、64 ビットのロング レジスタで 2⁶⁴ を処理できます。これは約 18 エクサバイトになります。 ただし、Windows では、Windows のバージョンに応じて、2 テラバイトから 4 テラバイト (TB) の間で予約できるメモリの量が人為的に制限されます。

メモリが予約されると、コミットされ、以前と同様に使用されます。 割り当て解除プロセスは、1 つまたは 2 つの小さいが重要な詳細を除き、主に逆になります。

まず、要求されない限り、Windows はメモリを "クリア" しません。 メモリが割り当て解除されると、Windows メモリ マップで 空 きとしてマークされます。 保持されているものは何でも存在し、別の割り当てによって上書きされるまでそこに残ります。 次に、要求されない限り、Windows はメモリのコミットを解除することはめったにありません。 先ほど述べたように、メモリ操作はかなりリソースコストがかかります。 そのため、プログラムで以前に割り当てられたメモリが必要な場合、Windows はそのメモリをもう一度必要とする可能性があると想定し、絶対に必要になるまでメモリのコミット解除を保留します。 最後に、Windows はメモリを "合体" することはありません。 つまり、Windows が解放するメモリは "集計" されることは決してありません。空きメモリのブロックは、空きメモリのブロックを大きくするために "一緒に移動" されることはありません。 (これらの関数はすべて、"ガベージ コレクション" と呼ばれるカテゴリにまとめられています。.NET Frameworkには、いくつかのガベージ コレクション機能があります。ただし、Skype for Businessは "ネイティブ" または non-.NET アプリケーションです)。

Skype for Businessは、可変サイズの多数のオブジェクトを 1 秒ごとに処理します。 私たちが望む素晴らしいツールにするには、これを行う必要があります。 連絡先の管理、予定表 (会議)、友人、親戚、同僚との IM の管理、音声とビデオの両方を使用した会話、デスクトップやウィンドウの共有などを行うように依頼します。 さて、遅れて、偉大なロバート・ヘインラインを引用するために、特に:「無料のランチなどはありません。

このようなさまざまなサイズの非常に多くのオブジェクトを管理すると、可変サイズのメモリ チャンクの割り当てと割り当て解除が作成されます。 時間が経つにつれて、メモリの断片化 (時には重大な場合) が発生し、Skype for Businessのメモリ 占有領域が増加します。

たとえば、この点を示す方が適切な場合があります。 Skype (またはネイティブ プログラムでは実際には) が 64 個のオブジェクト (番号 1 から 64) を割り当て、サイズはそれぞれ 4 K バイトであると仮定します。

図 6: 64 オブジェクト、それぞれ 4 KB のメモリを使用

これにより、256 KB のメモリ割り当てとコミットメントが発生します。 次に、プログラムに偶数のオブジェクトが必要ないため、それらを解放するとします。

図 7: 偶数のオブジェクトをすべて解放すると、128 KB のメモリが解放されます。

(VMMap または同様のツールを使用して) メモリ全体の全体像を見ると、コミットされた列の 1 つ ( ヒープ セクションにある 可能性がありますが、プログラムがメモリを要求した正確な方法によって異なります) が 128 KB 少なく、 Free セクションは 128 KB 増加していることがわかります。 タスク マネージャーでは、プログラムは 128 KB バイトのメモリのみを所有するようになりました。

次に、プログラムに格納する必要がある単一の 8 KB オブジェクトがあるとします。 これは単純なはずです。 結局のところ、それは128 KB無料です。 ただし、その 8 KB オブジェクトを格納しようとすると、128 KB の空き領域にメモリを格納するのではなく、新しいメモリ予約が作成されます。 これは、メモリを見ると、まだ 4 KB のチャンクにセグメント化されていることがわかります。 Windows には、8 KB オブジェクトを保持するのに十分なメモリ ブロックがないため、プログラムにより多くのメモリを予約してコミットする必要があります。

これはかなり工夫された例ですが、Skype のメモリ管理の難しさを示しています。 Skype は、簡単に定義できるサイズを持たない多数のオブジェクトを管理します。 これらのオブジェクトはすべて可変長です。 つまり、オブジェクトが格納され、解放されると (特に日数や週など)、長期間にわたってメモリの断片化が深刻になる可能性があり、Windows は新しいオブジェクトを格納するためにより多くのメモリを割り当てる必要があるため、メモリ占有領域が過度に増加します。

これにより 32 ビット クライアントで問題が発生する場合は、64 ビットと 32 ビットのアーキテクチャにより、メモリの制約がはるかに少ないため、64 ビット クライアントへの移行を頻繁に推奨します。 ただし、メモリの過剰な増加は、他の考慮事項の中でも、64 ビット クライアントでも不調を引き起こす可能性があります。 その他の考慮事項としては、システム メモリ全体、ディスク速度 (通常、プログラム メモリは Windows ページング ファイル内の仮想メモリによってサポートされるため)、開いている他のアプリケーションの数などがあります。 どちらの場合も、Skype for Businessメモリフットプリントが時間の経過と共に増加するにつれて、パフォーマンスが悪化します。 32 ビット クライアントの場合、これにより、Skype で必要な大きなオブジェクト (アプリケーション共有用の内部バッファーなど) が不足し、エラーが発生する可能性があります。

公平に言えば、メモリは時間の経過と同時に消費されるリソースの 1 つだけですが、最も明白 です 。 ハンドルの使用量は増加する可能性があり、スレッドは時間の経過と伴って増加し、ページプールメモリは増加します。 これらの増加のそれぞれは、プロセスと、場合によってはオペレーティング システム全体に影響を与える可能性があります。 これは、64 ビット クライアントでも、ユーザーが Skype を毎日 (または少なくとも毎週) 終了して再起動することをベスト プラクティスとして提案する無数の理由の 1 つです。

これに対して何をすればいいですか。また、Skype を強制的に再起動できますか?

Skype を強制的に再起動する方法はいくつかありますが、最適な方法は 1 つもありません。 もちろん、1 つの方法はユーザー教育です。 ほとんどの場合、ユーザーはデスクトップの使用のアービターであるため、1 日の出発時にサインアウトして Skype を閉じるよう教えるのは実用的です。 これは、カスタム スクリプトまたは実行可能ファイルを記述し、どちらかをタスク スケジューラ タスクとして実行することで、必須の手順として実行することもできます。 このアプローチは少し困難であり、"使用中" の場合でも Skype のサイクルを引き起こす可能性があります (ただし、これはタスク スケジューラの条件を通じて多少軽減できます)。 デスクトップとコンピューターの管理、潜在的な BIOS オプションなどのサードパーティの機会もあります。

要するに、Skype for Businessが毎日、または少なくとも毎週サイクルするのに最適です。 定期的にSkype for Businessをリサイクルするようにユーザーをトレーニングできる場合や、少なくとも奇妙な状況が発生した場合は、ヘルプデスクからの電話が大幅に減り、より多くの幸せなユーザーが増える可能性があります。