静的リストからオブジェクトを照会サーバー上のCPU使用率が急上昇している

Question

特定のレコードを表示しているときに関連するレコードを表示する関連する質問と同様の機能があります。関連するレコードは、ページがロードされるたびにdbを呼び出すことによって取得されていました。 dbの負荷を軽減するために、私はApplication_Startにロードするこれらのレコードの静的Listを作成しました.Lineqクエリを使用してこのリストをクエリしています。

ほとんどの場合、これはうまくいくようです。 dbの負荷が軽減され、SQLプロファイラに関連するレコードクエリがないことが示されます。私は昨晩この変更を進めていましたが、今朝私はIISワーカープロセスがCPUを100％にし、Webサイトが応答しないことがわかりました。私は以前のコードに戻って（私はdbを照会する）、物事はウェブサーバー上であったが、データベースの負荷が増加した。そこで私は新しいコードに再度切り替え、WebサーバーのCPU負荷を調べています。これは私が気づいたものです。

dbをクエリする古いコードを使用すると、IIS WorkerプロセスのCPU使用率はごくわずかであり、バリエーションはほとんどありません（タスクマネージャの[パフォーマンス]タブに直線が表示されます）。静的Listを作成してクエリを実行すると、IISワーカープロセスのCPU使用率が急上昇しています。ほとんどそれは1から5％の間ですが、今はそれ以上のスパイクがあり、私が見てきた最大値は観測を開始してから40％です。私はなぜこれが起こっているのだろうと重い負荷の下で、これはワーカープロセスがクラッシュする可能性があるかどうか疑問に思っていますか？ここ

StaticRecordsはブロッキング因子であってはならないので、静的リストを

if (validSearchLatLong && (usePincodeLatLong || distanceFilterLimit != distanceLimit)) 
     { 
      filteredRecords = StaticRecords.Where(job => LatLongDistance(centerLatitude, centerLongitude, job.lat, job.lon) <= distanceFilterLimit || (!string.IsNullOrEmpty(this.PreferredJobCity) ? job.city == this.PreferredJobCity : false)).ToList(); 
     } 
     else 
     { 
      filteredRecords = StaticRecords.Where(job => (this.PreferredJobCity != "" ? job.city == this.PreferredJobCity : (this.City != "" ? job.city == this.city : (state != "" ? job.state.Trim() == state.Trim() : false)))).ToList(); 
     } 

     if (RecordsearchFilter.JobCategories.Count > 0 && RecordsearchFilter.EnableFilter) 
     { 
      filteredRecords = filteredRecords.Where(job => this.RecordsearchFilter.JobCategories.Contains(job.JobCategoryClass)).ToList(); 
     } 
     else 
     { 
      filteredRecords = filteredRecords.Where(job => MatchJobCategories(job.JobCategory, (short)this.jobCategory.SqlId) > 0).ToList(); 
     } 

リストを照会されたコードの一部は、複数の同時リーダーをサポートしています。そしてその後、私はfilteredRecordsを作成しています。これは、他のスレッドから独立しているはずの新しいフィルターリストです。

CPUのスパイクの原因として、IISワーカープロセスの以前のクラッシュが発生した可能性があります。

============ EDIT ==============

私は今のクラッシュが原因このコードに発生していないことを知っているが、別のバグ。静的Listアプローチは安定しており、その目的を達成するうえでうまくいっているようです。

しかし、私の質問はまだ残っています、なぜCPUのスパイクですか？ StaticRecordsが はブロッキング係数ではありませんので

私は

一覧を言って、同時に複数のリーダをサポートしています。そしてその後、私はfilteredRecords を作成しています。これは、他の スレッドとは独立したフィルタリングされた新しいリストです。

私は間違っていますか？

Answer 1

通常、インデックスを最適化すると、特にSQL Serverのクエリが非常に効率的です。

新しいStaticRecordsアプローチでは、すべてのアイテムのメモリ内スキャンが必要で、それぞれにWhere述語を実行する必要があります。これは、特に多くのアイテムがStaticRecordsにある場合、CPU使用率を増やす原因になります。プロファイラをつけてみてください。一般に、SQL Serverとメモリ内のフィルタリングの両方で実行すると、このようなフィルタリングの方がはるかに優れたパフォーマンスが期待できます。

Answer 2

パフォーマンスの問題は、おそらくStaticRecordsでListをスキャンによるものです。メモリにデータを読み込み

一度罰金ですが、あなたはそれを効果的に照会するために、より効率的なデータ構造を必要とするように見えます。また、LINQを使用してクエリを実行するという考え方に戻ってみることもできます。

限り、何があなたのクラッシュ、100％のCPUスパイクを引き起こしたとして、私はあなたが投稿したコードの明らかなエラーが表示されません。