BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース サーバーサイドパフォーマンス、.NET 4.5、Bing

サーバーサイドパフォーマンス、.NET 4.5、Bing

ブックマーク

原文(投稿日:2012/07/25)へのリンク

 

USのWeb検索のシェア33%以上を持つBingとYahooは、.NET 4.5 RCアプリケーションを製品利用している最大の利用者のひとつである。MicrosoftのBingと.NETチームは密接に作業しており、結果として、拡張機能が大規模な.NETサーバーを実行するのに誰にとっても便利であることを証明する拡張機能のセットをもたらした。

Channel 9のインタービューにおいて、 “.NET GC開発であるMaoni Stephens氏、パフォーマンスアーキテクトのVance Morrison氏、そしてBingフロントエンド開発者であるMukul Sabharwal氏が実践における.NET 4.5に関する議論に参加した。” 興味深いハイライトのひとつはマルチスレッドJITコンパイラである。長時間オンラインを維持する傾向にあるサーバーにとってJITは重要ではないと考えるだろう。しかし、ASP.NETフレームワークでは、Ngenのようなテクニックはうまく動作しない。RazorやWebフォームで書かれた数千のビューがあったとしても、NGenは単純に見ることができない。またそれらは、サーバーの再起動やプロセスがリサイクルのたびに再コンパイルが必要になる。

.NET 4.5とマルチスレッドJITを使ったBingは、起動時間が半分に削減された。この恩恵の大半は、以前のJITされたコンポーネントの一覧を維持することによってもたらされている。この一覧は、起動時にバックグラウンドでJITコードをプリエンプティブにするために使用される。実際にコードを実行しようとするスレッドと干渉を避けるため、多くのコアを持っていたとしても、JITするスレッドは2~3コアに制限される。

.NET 4.5で重視されているのは、Event Tracing for WindowsまたはETWである。.NETアプリケーションが独自のETWイベントを作成することを可能にする新機能EventSourceクラスによって、この一部がサポートされている。 その他の改善点は、スタックトレースに関するものである。以前のバージョンでETWは、プリコンパイルされていないコード(たとえば.NETやJavaScript)に対する64ビットサーバーのコードに対する正確なスタックトレースは提供されていなかった.NET 4.5とWindows Server 2012では、デバッガのアタッチをしなくてもスタックトレースが取れるようになった。

残念ながら新しい問題が、非同期プログラミングによって発生している。非同期モデルでは、スレッドを処理するプロセスはリクエストを作ったスレッドである必要がない。これにより、もともとのリソースを要求したものと新しいスタックトレースを組み合わせることが非常に困難になる。加えて、この領域にさらなる手を加えるため、MicrosoftはPrefViewの可視化ツールのプロトタイプを使ってこの問題に光を当てることを期待している。最終的にMicrosoftはこのサポートをVisual Studioに移したいと考えている。

次のインタビューでは、.NET 4.5サーバーアプリケーションではデフォルトでオンになったバックグラウンドGCについて紹介している。一般的な固定化されたメモリの問題について言及した。固定化によって実際にどれだけのコストがかかるかを確定するために、固定化が作成または変更されるたびにETWイベントが発生している。

.NETにおける固定化されたオブジェクトは必ずしも高価とは限らない。それらはGCが移動しようとしているメモリをブロックしたときにだけ問題になる。そのためMicrosoftは現在、頻繁に必要になるオブジェクト(たとえば、非同期バッファ)を再利用できるように固定化しておくことを推奨している。そうした場合、必要な時だけ固定化され、最終的に他の移動されたくない長寿命のオブジェクトとともに第2世代ヒープに置かれる。

その他のオプションとして、マネージドバッファを固定化する代わりに単純にアンマネージドバッファを確保する方法がある。ここでのトレードオフは、固定化されたメモリに対してGCを実行するペナルティをときどき払う代わりにマネージドメモリにバッファをコピーするための代償を払う必要があることである。

長期的にMicrosoftは、再利用可能なバッファポールを作成することができるフレームワークのサポートを提供したいと考えている。

.NETのGCに関するいくつかの注意点:

  • 32ビットOSでは.NETのヒープはおよそ2GBである。64ビットOSでは、Microsoft10 GBは珍しくなく少数のカスタマは50 GBのヒープを持っている。ただし、2 GBを超える配列が必要な場合、gcAllowVeryLargeObjects設定をオンにする必要がある。
  • .NETサーバーGCでは、論理プロセッサごとにヒープが存在している。小さなオブジェクトヒープは必要に応じて再調整されるが、.NET 4.5以前では大きなオブジェクトヒープは存在していなかった。
  • 複数のCPUグループにおけるNUMAアーキテクチャを使うには、GCCpuGroup設定をオンにするべきである。
  • パフォーマンスが必要な操作の間、SustainedLowLatencyモードを使ってGCを維持的にオフにすることができる

 

この記事に星をつける

おすすめ度
スタイル

BT