Metro スタイル アプリからメモリを回収する

Building Windows 8

Windows エンジニアリング チームによるブログ

Metro スタイル アプリからメモリを回収する

  • Comments 2

最近のオペレーティング システムでは、システムのリソースに対する見方が変わってきました。フォーム ファクターに関係なく、OS にとってリソース利用率を効率的に管理することが以前より重要になっています。現在、エンド ユーザーにとって全体的なパフォーマンスが向上しない場合でも、1 つのプロセスが利用可能なリソース (メモリ、CPU、ディスク I/O) を簡単に消費しすぎます。OS の役割はまさにリソースのバランスを取り、ユーザーが PC で実行したいすべての処理を完了できるようにすることです。異常なソフトウェア (リソースを無限に消費する状態に陥るソフトウェア) に対処するために、ほとんどの OS 実装には手動制御が存在します。ソフトウェアが悪意のあるものでなくても (たいていはそうですが)、リソース割り当て API が複雑なため適切に動作するソフトウェアを構築するのは難しいものです。WinRT の最新の API セットは、PC の "支配権を得て" いなくても処理を終えるソフトウェアをプログラマが簡単に構築できるようにするためのものです。これにより、すべての PC フォーム ファクターとすべてのソフトウェアで優れた効果があります。

この記事では、アプリが中断したときでもメモリを回収する舞台裏での試みと、開発者による懸念なくこのすべてがどのように行われるかについて、Fundamentals (基礎技術) チームのグループ プログラム マネージャー Bill Karagounis が詳細に説明します。
--Steven


以前のブログ記事では、Windows ランタイムを使った Metro スタイル アプリケーション モデルについてお話ししました。このアプリ モデルの重要な特徴は、アプリがユーザーから見えなくなると中断することです。他のアプリのために CPU が節約され、バックグラウンド アプリによりリソースを消費するアクティビティが実行されなくなるため、バックグラウンドで Metro スタイル アプリを中断するのは良いことです。その結果、バッテリ寿命が延び、応答性が良くなります。この点については、Sharif Farag と Ben Srour のブログ記事「アプリケーションの電力効率を向上させる」で詳細に説明されています。

しかし、これらのアプリが中断中に使うメモリについてはどうでしょうか。以前の記事で、実際にはこれは OS によって処理されるので、中断されたプロセスがあっても他のプロセスがメモリ残量の逼迫に直面することはないと指摘しました。これは、設計において注意が払われた重要なポイントでした。しかし、皆さんの中にはこのしくみを知りたがっている方もいらっしゃることと思います。

Windows 8 Consumer Preview 以降、Windows はシステムでメモリ残量の逼迫を検出すると必ず、中断された Metro スタイル アプリが保持しておくはずのメモリをほぼすべて振り替えるようになりました。Windows 8 は、アプリを終了しなくてもこのメモリを回収できます。


ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

メモリ、応答性、Metro スタイル アプリ

どのような種類のアプリ (Metro スタイルまたはデスクトップ) でも、生成されたメモリ要求に関係なく、Windows はそのアプリのために物理メモリの割り当てを管理しようとします。Windows は常にこのように動作することで、アプリによる将来のメモリの必要を見込んで利用可能なメモリを確保します。以前にアプリにメモリが "割り当てられている" 場合でも、Windows はアプリがメモリを使おうとしたときにのみそのアプリに物理メモリを割り当てるように注意を払います。メモリのページが長時間使用されていない場合、Windows はアプリからメモリの一部のページ アウトまたは振り替えも行います。

目標は、要求側のプロセスにメモリを拒否することではなく、物理メモリの割り当てをできる限り (ユーザーが実際にアプリに触れるまで) 遅らせることです。これは多くのリソースと同様、ソフトウェアへの割当量が不足する傾向があるためです。OS は、これらの要求がすべて集まる場所であり、十分な割り当て要求をすべて満たすと最終的にはあらゆるプロセスのメモリが足りなくなるという情報を得ています。これによって、処理が完了しないだけでなく、システムが本質的にロックされてしまいます。これは、仮想メモリの場合でも生じます。RAM を使い果たす代わりに、PC はページをディスクからスワップ インおよびスワップ アウトするだけです。

いずれかの時点でプロセスに割り当てられた物理メモリは、プロセスの "ワーキング セット" と呼ばれます。プライベート ワーキング セットは、プロセスに特有の物理メモリを表します。プロセスは、"共有された" (複数のプロセスが参照可能な) 物理メモリの他のページも使います。タスク マネージャーの [Processes] (プロセス) ビューを見ると、特定のプロセスのメモリが実際にその現在のプライベート ワーキング セットとなっています。メモ: 簡単にするため、この記事で "ワーキング セット" というときは "プライベート ワーキング セット" を意味します。

システムの起動時に利用可能なメモリが少ない場合、OS はシステム内の他のプロセスの必要を満たすために振り替え可能な物理メモリのページの有無について、すべてのプロセスを調べます。必要な場合は、メモリのページ アウトも行います。デスクトップ アプリの場合、Windows はメモリの最も重要な (頻繁にアクセスされる) ページをアプリのワーキング セットに保持します。これは、デスクトップ アプリではいつでも (バックグラウンドの場合でも) コードを実行できることが期待されるためです。しかし、これで微妙なバランスが取れています。デスクトップ アプリから削除する必要があるメモリのページが多すぎる場合、(ディスクにページングされたメモリをアプリが見えないところで使おうとするために) 追加ディスク I/O が生じるのでアプリの応答性に影響を与える可能性があります。

Windows のメモリ管理について詳しくお知りになりたい場合は、Mark Russinovich の「Mysteries of Windows Memory Management Revealed」(英語) というビデオの第 1 部第 2 部をご覧ください。

一方、Metro スタイル アプリは、フォアグラウンドでなくなると通常中断されるという点がデスクトップ アプリとは異なります。中断されると、メモリをまったく使わなくなります。

以下のスクリーンショットの線で囲んでいるアプリは、ワーキング セットにメモリを保持している中断された Metro スタイル アプリの例です。

それぞれ 63.3MB ~ 3.8MB のメモリを使った 11 個の中断されたアプリが表示されている、タスク マネージャーの [Processes] (プロセス) タブ

メモリを保持している中断されたアプリ

メモ: Consumer Preview ビルドでは、既定では中断状態が
タスク マネージャーの [Processes] (プロセス) ビューに表示されません。 (表示) メニューのオプションで
表示されるように選択する必要があります。

システムでメモリ残量が逼迫していない場合、実際には中断したアプリのワーキング セットにメモリを残しておくことをお勧めします (これが最も効率的です)。メモリ残量がある程度逼迫している場合、これらの Metro スタイル アプリが中断されていることから、アプリを終了しなくても、それらのワーキング セット内のほとんどすべてのメモリを他のアプリ用に戻すことができます。

中断された Metro スタイル アプリからメモリを回収する

Windows 8 Consumer Preview では、システムが逼迫を検出したとき追加のメモリを取得するために、中断された Metro スタイル アプリの (プライベート) ワーキング セット全体をディスクに効率的に書き込むことができます。

このプロセスは、特定のアプリを休止状態にし、ユーザーがもう一度そのアプリに切り替えたときに再開するプロセスと似ています。私たちは Metro スタイル アプリの中断/再開メカニズムを活用して、アプリのワーキング セットを空にしたり再入力したりしています。

イベントの順序は次のようになります。

    1. Process Lifetime Manager (PLM) は、システムでメモリの逼迫を検出し、中断された Metro スタイル アプリを収容している特定のプロセスのワーキング セットを空にするよう Memory Manager (MM) に依頼します。

フロー図: メモリ 1.6/2.0 GB (80%)、Process Lifetime Manager (PLM) への矢印、Memory Manager (MM) への矢印、PLM から 3 つの中断された Metro スタイル アプリへの 3 本の矢印

    1. MM は、メモリのページをアプリのワーキング セットからオペレーティング システムの変更ページ リスト (再利用する前に内容をディスクから書き出す必要があるメモリのリスト) に移動します。

前: 中断されたアプリのメモリ ページを変更ページ リストに移動する、ワーキング セットは 40.3 MB。移動後のワーキング セットは 0.7 MB で、変更ページ リストには新しいアイテムがある。

    1. 通常の MM ポリシーに定められているように、変更ページ リスト上のワーキング セット ページは非同期的に書き出されます (都合の良い時にバックグラウンドで書き出され、メモリ残量逼迫時に書き込みがトリガーされます)。

変更ページ リストはディスクへの矢印で表示、ページをディスクに非同期的に書き込む

    1. 中断されたアプリのワーキング セットがディスクに書き込まれた後でも、プロセスから削除されたメモリ ページはオペレーティング システムのスタンバイ リストにそのまま残されます。これは、必要に応じて他のアプリに振り替えることができる、有用なメモリ ページのキャッシュです。元のプロセスが再度これらのページを必要とする場合、すぐに戻されます。

変更ページ リストとスタンバイ リストの両方に表示されたページ

アプリのワーキング セット ページがまだ物理メモリ (変更ページ リストまたはスタンバイ リスト上) にあるときに、ユーザーがそのアプリに切り替えた場合は単純です。ページがアプリのプロセスにすぐに戻されます。ページが使用できなくなった場合、Windows は最適化された方法でディスクからアプリのワーキング セットに読み込みます。

"メモリの回収" の実行

このしくみの感触をつかむため、実際の実行コードで例を見てみましょう。

最初の状態は前のスクリーンショットに示されています。いくつかの Metro スタイル アプリが PC で実行されており、RAM は 2 GB です。Metro スタイル アプリはバックグラウンドにあるため、Windows により中断されています。このとき、さらにアプリを開いてシステムでのメモリ使用量を増やし、新機能をトリガーしました。

以下のスクリーンショットでは、メモリをさらに逼迫させて、前記の動作を引き起こすために、いくつかのアプリを開いたことがわかります。スクリーンショットに示すとおり、Windows は中断された Metro スタイル アプリのワーキング セットを空にしました (線で囲まれた部分)。

タスク マネージャーの [Processes] (プロセス) タブ、中断された各アプリのメモリ使用量はすべて 1 MB 未満。

空になった Metro スタイル アプリのワーキング セット

元の Metro スタイル アプリの "回収前" と "回収後" のワーキング セットを比較してみましょう (27 個の起動中アプリすべてをタスク マネージャーに表示できないため、"回収後" 状態で存在したいくつかのアプリは表示されていません)。

Metro スタイル アプリ

回収前のワーキング セット (MB)

回収後のワーキング セット (MB)

Flixster

23.5

0.5

Flow

15.2

0.6

Kindle

23.1

0.5

LiveComm

3.8

0.3

Lyrics

65.3

0.9

Maps

28.1

0.8

Remote Desktop

21.0

0.5

SkyDrive

23.1

0.5

ストア

26.9

0.6

Weather

42.0

0.8

Windows リーダー

9.2

0.4

ですから、この例では中断されたアプリをシャットダウンせずに 250 MB 以上の物理 RAM を解放し、他のアプリに使えるようにしました。

ワーキング セットを再度読み込むときの応答性

この新機能は、中断されたアプリのワーキング セットの内容が空にされ、アプリに再度切り替えるときのアプリの応答性によってテストできます。

私は、このテストを実行しているとき、"Lyrics" アプリを応答性のめやすとして使用しました。Lyrics アプリでは、歌の歌詞の表示や、ミュージック ビデオの再生が可能です。Lyrics アプリは、バックグラウンドになると中断され、再生は停止されます。

ワーキング セットが空になるまでメモリ使用量を増やしたら、追加のアプリを開いてしばらくシステムを使用し、アプリへのスワッピングによりディスクからワーキング セットを読み込むようにしました。次に、Lyrics アプリへの再切り替えをトリガーしました (以下を参照)。

タスク マネージャーの [Processes] (プロセス) タブ、Lyrics アプリは現在 97.4MB のメモリを消費している

Lyrics アプリのワーキング セットに再入力される

私が見ていた主なめやすは、アプリへの再切り替えをトリガーしたときからもう一度サウンドが聞こえるまでどれくらい時間がかかるかです。ローエンド コンピューターでは、メモリ負荷が高いと、ワーキング セットがディスクから読み込まれたアプリに再切り替えした場合と、ワーキング セットがまだメモリ内にある場合の応答性に違いがわかりにくくなります。しかし、かかる時間は変化します。ワーキング セットが大きくなればなるほど、ディスクからの読み込みにかかる時間は長くなります。私たちは、引き続き Metro スタイル アプリのディスクへの書き込み量を減らし、この機能をさらに最適化してまいります。

この機能は、Consumer Preview リリースを使っていればだれでも自分で試すことができます。多数の Metro スタイル アプリとデスクトップ アプリを開いてメモリ残量がある程度逼迫した状態にし、ワーキング セットが空になっている中断された Metro スタイル アプリにもう一度切り替えるだけです。

メモ: メモリ残量が危機的範囲になった場合、Windows はこれまでどおり Metro スタイル アプリを終了します。ただし、この機能により、システムはこれまでより多くのアプリケーションを実行してもそのポイントに到達しなくなります。

ワーキング セットへの最適な読み込み

ディスク上にワーキング セットがある中断されたアプリにもう一度切り替えたときに応答性を実感できるようにするため、ワーキング セットの書き出し方法を最初の段階で最適化し、できる限り効率的に読み込みが行われるようにしました。

中断された Metro スタイル アプリのワーキング セットを書き出すとき、ワーキング セット ページは連続してディスクに書き出されます。この結果、少数回の大きなシーケンシャル ディスク読み込みを使ってデータをプロセスに戻すことができます。以下のスクリーンショットは、アセスメント & デプロイメント キット (ADK) に付属する Windows パフォーマンス アナライザー (WPA) ツールのものであり、このプロセスで行われるディスク読み込みを仮想的に表現しています。拡大部分はワーキング セットの "読み込み" I/O です。アプリのワーキング セットに再入力する際のシーケンシャル ストリームがはっきりわかります。

Windows パフォーマンス アナライザー

アプリのワーキング セットに再入力するシーケンシャル読み込み I/O (WPA ツール)

ほとんどのストレージ デバイスで、シーケンシャル データの再読み込みは非常に高速です。ほとんどの回転ディスクでは 1 秒あたり 50 ~ 100 MB になります。ストレージ デバイスがフラッシュ ベース (SSD など) の場合、読み込みは 1 秒あたり 200 MB 以上になります。

中断されたアプリのワーキング セットをメモリに戻す際、多くのアプリで I/O にかかる秒数が短くなることが期待されます。

まとめ

明らかに、あらゆるフォーム ファクターのすべての PC の物理メモリは限られています。より多くのメモリを要求する多くのプログラムを実際に実行する限り、物理メモリを増やしてもメモリ管理の問題は変わりません。

巨大な RAW イメージの写真編集、メモリ内データベース、非常に多くのスプレッドシートなど、最近のソフトウェアはさまざまな種類で進化し続け、ますます多くのメモリを使うようになっています。そうしたソフトウェアが WinRT ベースの実装であるか、またはデスクトップ実装であるかにかかわらず、OS は増え続けるこれらのメモリ要求を管理できるように進化する必要があります。WinRT は、プログラマにとって、応答性と処理の完了の観点からユーザーを最優先しつつ、必要なすべてのメモリにアクセスできるようにする API を使用するチャンスとなります。ぜひ Windows 8 Consumer Preview でこの機能を試すことをお勧めします。

-- Bill Karagounis

  • Loading...
Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post