IISにOSSをインストールするための情報サイト [IIS de OSS 64bit]

IIS de OSS 64bit > Windows7 > Windows7のカーネル改善点

Windows7とWindows Server 2008 R2のカーネル

まずはじめにWindows7とWindows Server 2008 R2は同一のカーネルツリーからビルドされているという事を知っておいて下さい。Windows7とは書いてありますがWindows Server 2008 R2のカーネルも同様の実装となっています。

Windowsカーネルの開発体系

リリース後はWindowsUpdateを作るためのGeneralDestributionRelese(GDR)とHotFixを作るためのLimitedDistributionReleaseの2つのソースツリーで開発を進め、サービスパックのリリース毎にブランチをリセットしているらしい。

なぜサーバは「R2」とマイナーバージョンアップなのに、クライアント製品は「Windows7」とメジャーバージョンアップになっているのか

今回のOSのバージョンは7と言っているが内部的には6.1となっている。これは、このリリースタイミングで存在するアプリケーションの互換性などのチェックの実装がバージョン7を想定しておらず、6.x互換に対応しているアプリケーションが多いためである。 私感だが、やはりVistaの市場イメージが悪すぎて「Vista R2」などと謳っても良い事なさそうだったから思い切ってバージョンアップしちゃったのかなと思います。Windows上で動くソフトを作る会社の事を考慮すると絶対にメジャーバージョンアップの時期じゃなさそうなので6.1という内部バージョンアップにはしているけれど、実際はカーネル上かなり手を入れているので絶対6.1じゃないっすよねwまぁ、下位互換性に自信があるから敢えて6.1にしたんでしょうね。この自信に期待します。あれ、でもこれってWindows2000からWindowsXPへの変更の時と同じか?

具体的な改善点

構成の大幅な変更

Windows7のカーネルの改善に当たって、まず「MinWin」という最小Windows構成を作りコア部分を独立させた。これはメモリ40M程度で動く事が出来るWindowsの本当のコア部分と言える。この「MinWin」として肥大化したOSから本当のコア部分だけを独立させるという作業自体はマイクロソフト的にはずっと目指して開発してきたものらしい。

具体的にはsystem32フォルダ内を見るとこれまでの「Kernel32.dll」が「Kernelbase.dll」などDLLが変更になっている。この変更はそのままでは既存のアプリは当然エラーになってしまうが、ここではVirtual DLLを利用する事によって仮想的にKernelbase.dllにアクセスさせるような仕組みが動いている。 System32以下のapi-ms-win-core-xxxx.dllという形でリファクタリングのDLLが多数存在する。

Win32K.sysからの処理をCSRSS(Client/Server Runtime Subsystem)経由で処理していたものをconhostという場所を経由して処理させるようにして、理論上CSRSSが落ちないようにした。(これよくわからない。。)

使用メモリの削減

OS全体で400項目ほどメモリ使用量を減らした結果10%~20%ほどメモリ使用量が軽減されている。 →個々のコンポーネントでそれぞれ十分すぎるほどキャッシュを保持していたのでそこを削っている。

複数Window時のメモリ効率化

Desktop Window Manager(DWM)のアーキテクチャを見直し、Window毎のメモリ使用量を半分にした。今まではWindowが増えるごとにメモリ使用量が等倍で増えているような感じだったが、この改善でメモリの増加量がかなり抑えられた。

レジストリの格納をMemory Mapped PoolからPagedPoolに変更した。

VistaやWindowsServer2008ではシステムキャッシュ、PagedPool、システムコードは同一のワーキングセット(メモリの利用グループみたいなもの)で管理していたが、Windows7、WindowsServer2008R2では3つ独立したワーキングセットに分割した。 →Vistaなどでは大きなファイルをコピーしているとOS負荷が高まったがWindows7ではページングが発生しないためOS全体の負荷が軽くなった

Core Parking機能

最新のプロセッサではコアがアイドル時にソケットレベルでパワーマネジメントを行う製品が出てきているので、それに対応しソケットレベルでパワーマネジメントを行うようにカーネルを実装した。Core Parkingでは50msでCPU使用率を測定している。 と上記のように上手い事マネジメントするためのポリシーは存在するが、AffinityやThread Idle Processorを設定している場合はその設定が優先されるので注意しましょう。

Unified Background Process Manager(UBPM)

バックグラウンドで多数動いているサービスがあるが、特に動作してない場合は寝かしておく事ができるっぽい機能だったと思う・・・

Fault Tolerant Heap(FTH)

Vistaまででオンラインで報告される不具合の15%がヒープクラッシュだったらしい。 更にシャットダウン中のクラッシュの3割がヒープ関連だとか。従来Shimというクラッシュ報告ベースでのメモリ確保を増やす仕組みはあったが、この仕組みをダイナミックにローカルでモニタリングしてヒープ破壊が起きないように事前にメモリを確保しておくなどアプリをあまり信用しないように(w)工夫が凝らされている。 このバージョンではローカル環境内のみでShimが動くようにしたらしい。 NTDLL内にてクラッシュが1時間以内に2~4回発生するとAppcompat Shimが起動し、傾向から上手い事メモリの確保を調整するようにして不正終了しないようにさせるらしい。

Process Refrection

従来は不正終了した場合には次回再発時にダンプをとるしか対応が無かった。今回は異常発生時に該当プロセスをforkする感じでコピーを作りダンプがとれるようになったっぽい。 プロセスダンプは「procdump.exe -r プロセスID」で取得できる

仮想アカウント

VASvcで作成可能らしいが、まだ未検証。

マルチスレッド

ユーザーモードスケジューリング(UMS)の改善

  • カーネルモードとユーザモードを分離して利用できるようにした

256論理プロセッサのサポート

64論理プロセッサを1グループとして最大4グループまでサポートしている NUMAの場合はNUMA単位で上手く分けられるようにグループをわけるようにしている

メモリ・CPUの改善

  • PFN Lockの削除
  • Dispatcher Lockの廃止

FibersモデルとThreadモデル両方あるがDispatcherロック解除の恩恵でパフォーマンスがかなりアップしたらしく、SQL ServerチームではFibersかThreadかという選択でのパフォーマンスアップをせずに既存のテクノロジーのままこの項での改善で大分満足したっぽい。

結果的なパフォーマンスアップ度合い

具体的には同一スペックのマシンでのブート時間として以下のような秒数が出ている

Win740秒ちょい
Vista70秒

コメント


トップ   差分 バックアップ リロード   一覧 単語検索 最終更新   ヘルプ
Last-modified: 2010-02-21 (日) 09:30:19 (3215d)