2

.Net4.0を使用したゲームサーバープロジェクトがあります。私はMemoryCacheクラスを使用しており、複数のユーザーが同時に変更できる多くのオブジェクトをキャッシュして、I/Oと同期を高速化しています。最近、ゲームが公開された後、デザインに問題があることに気づきました。これらのキャッシュされたオブジェクトは長寿命のオブジェクトであるため、すべてGC gen 2に移動し、割り当てを解除するのが困難です。そのため、gen 2ヒープは非常に大きくなり（5日後に約8ギガバイト）、完全なGCには時間がかかりすぎます。

グーグルで何日も過ごした後、大きな第2世代のヒープを回避するために、長寿命のオブジェクトを使用しないのがおそらく最善の方法だと思います。しかし、私は何をすべきかわかりません。これらのオブジェクトはdbから読み込まれ、ユーザーリクエストによって変更され、dbに保存されます。複雑すぎて、byte []に​​シリアル化して、memcachedに保存することはできません。シリアル化することもできます（memcachedから読み取る->変更->書き込み）。 back）もスレッドセーフな操作ではありません。

助言がありますか？

4

3 に答える 3

0

このサーバーがすべてをローカルにメモリにキャッシュする必要がある理由はありますか？サーバーからデータベースに接続している場合、なぜそのような問題が発生するのか、なぜそれらをメモリにキャッシュするのかを理解できます。ただし、Memcachedなどの複数のアプリケーションインスタンスで機能するキャッシュフレームワークはたくさんあります。

確かに、メモリに保存するほど速くはありませんが、オブジェクトの取得に関して実際にパフォーマンスの問題がありますか、それとも速度の問題があることを先取りして事前に最適化しましたか？アプリケーションを水平方向にスケーリングし、メモリへのキャッシュを停止して別のシステムに責任をプッシュすると、各サーバーインスタンスの速度が少し遅くなる可能性がありますが、スケーリングははるかに簡単で迅速になります。

于 2012-10-15T12:56:37.120 に答える
0

私はいくつかの提案を考えることができます

  • 最初にサーバー GCを使用してみましたか。これにより、ヒープが複数のヒープ (プロセッサごとに 1 つ) に分割され、複数のプロセッサ マシンでのスループットを向上させるために並列に収集されます。これは、問題を完全に解決するのに役立つ場合があります。
  • これでも問題が解決せず、第 2 世代ヒープの収集にまだ時間がかかりすぎる場合は、ある種の外部キャッシング フレームワーク (Memcached など) の使用を検討する必要があります。詳細を知らなくても、これはおそらく私の好みのアプローチでしょう。
  • 別の方法として、新しいオブジェクトの割り当てと割り当て解除ではなく、オブジェクト プールを使用して既存のオブジェクトを再利用することを検討することもできます。

私が考えることができる唯一の他の解決策は、フルGCが発生しようとしているときに別のサーバーサーバーにリダイレクトするようなものです（フルGCが発生しようとしているときの通知は.Net 3.5 SP1機能です）しかし、これはもっと多くなる可能性があります上記の 2 番目のオプションよりも複雑です。

于 2012-10-15T13:27:36.700 に答える
0

キャッシュされたオブジェクトの有効期間を構成しないのはなぜですか? N 時間/日使用されないオブジェクトをそれほど多く保存する必要はないかもしれません。

役に立たない場合は、キャッシュ メカニズムを変更する必要があります。また、膨大な量のオブジェクトを長時間保存する必要がある場合は、複数のサーバーが必要になります。オンプレミスホスティングまたはクラウドを使用できますが、どちらにも分散キャッシュと呼ばれるキャッシュメカニズムがあります。.NET のオンプレミスでは、Windows Azure を使用するクラウドでは AppFabric キャッシュである可能性があります。これも AppFabric とかなり似ています。

したがって、ライフタイムが役に立たない場合は、クラウド (Windows Azure、Amazon AWS) またはオンプレミス (AppFabric) で分散キャッシュを使用することをお勧めします。

于 2012-10-17T14:11:53.670 に答える