1713839445
2024-04-22 14:13:42
時々、私の仕事は簡単で、一度見るだけで問題が解決することがあります(この例のように、見るべきところを見られる幸運なとき) Varchar はパフォーマンスに悪影響を与える可能性があります – Quan Mai のブログ (vimvq1987.com) )。 時々、それは難しいです。 何度ぼんやり画面を見つめて、昼寝するか、コーヒーを焙煎するか、散歩するか(嘘ですが、私は歩きません)と思ったことが何度あったか数え切れません。考えがまとまらず、どうにもなりません。 ソフトウェア診断エンジニアの人生もそんな感じで、「この謎を解くには何が必要か」という謎を解くこともあります。 通常、あらゆる場所にはさらに多くの点が散在しています。あなたの仕事は、どの点が意味をなし、どの点が意味を持たないかを判断し、問題の解決に関連する点をどのように結び付けてストーリーを伝えるかです。
今日の話は、インデックス作成ジョブの検索を実行した後、DXP 上でスケジュールされたインスタンスのメモリ使用率が高くなり続けるというお客様からの苦情についてです。 言語設定のパフォーマンスを最適化するために構築されたカスタム ジョブがありますが、考え方は同じです。コンテンツを読み込み、シリアル化し、インデックス作成のためにサーバー エンドポイントに送信します。 実際、これは、特にインデックス付けが必要なコンテンツが多数ある場合 (基本的に、コンテンツの数 x 言語の数 x コンテンツの複雑さ)、メモリを大量に消費するジョブです。 このようなジョブ中にメモリ使用量が増加するのは正常です。アプリケーション (見方によってはランタイム) がジョブを実行しているため、コンテンツをメモリにロードする必要があり、使用可能なメモリがある場合は、メモリは何か有益なことに使用されなければ、非常に無駄になります。 また、コンテンツはキャッシュされているため、アプリケーションはそのメモリをすぐには解放しません。 メモリは、キャッシュの有効期限が切れた場合、またはアプリケーションにメモリ不足がある場合にのみ再利用されます(つまり、アプリケーションがオペレーティング システムに追加のメモリを要求し、OS が「何も残っていない」と拒否した場合)。 キャッシュの有効期限が切れた場合でも、アプリケーションが常に圧縮してメモリを OS に解放するとは限りません (LOH など)。
ここで問題となるのは、顧客のアプリケーションが 25 GB のメモリを無期限に保持することです。 24 時間待機しましたが、メモリ使用量は依然として高いです。 アプリケーションは問題ないように見えます。メモリの問題 (メモリ不足など) が原因でクラッシュすることはありませんが、顧客に混乱と心配を与えます。 ゲームが始まりました。
この場合、意味がわからないのは、カスタム インデックス ジョブがあるとしても、それは依然としてスケジュールされたジョブであるということです。 また、スケジュールされたジョブの場合、コンテンツには非常に短いスライド有効期限 (デフォルトは 1 分) が設定されているはずです。 ただし、メモリ ダンプ内のキャッシュ エントリからは別のことが分かります。 キャッシュ エントリの大部分には、12 時間のスライド有効期限があります。 これは、メモリが高いままである理由を少なくとも部分的に説明します。 スライド時間が長い場合、キャッシュが期限切れになる前に少なくとも 1 回はヒットし、期限切れがリセットされる可能性が高くなります。 十分なヒットがある場合、(コンテンツを編集するなどして) キャッシュを積極的に削除するまで、キャッシュは実質的にメモリ内に永久に残ります。
0000753878028910 0.77kb 0 12:00:00 2/16/2024 5:58:43 AM +00:00 EPPageData:601596:en__CatalogContent
0000753878029DC0 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1345603:es-pr__CatalogContent
00007538781C7F48 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1351986:es-pr__CatalogContent
00007538781C8058 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1346230:es-pr__CatalogContent
00007538781C8168 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1351988:es-pr__CatalogContent
00007538786FA8E8 0.77kb 0 12:00:00 2/16/2024 8:14:53 AM +00:00 EPPageData:1049433:no__CatalogContent
00007538786FC598 0.78kb 0 12:00:00 2/16/2024 9:32:28 AM +00:00 EPPageData:1088026:es-pr__CatalogContent
00007538786FD9E0 0.77kb 0 12:00:00 2/16/2024 8:14:53 AM +00:00 EPPageData:1049435:no__CatalogContent
0000753878700770 0.77kb 0 12:00:00 2/16/2024 7:52:53 AM +00:00 EPPageData:1029725:da__CatalogContent
0000753878706528 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1351990:es-pr__CatalogContent
0000753878706638 0.78kb 0 12:00:00 2/16/2024 2:59:39 PM +00:00 EPPageData:1350104:es-pr__CatalogContent
00007538787A2F80 0.77kb 0 12:00:00 2/16/2024 8:14:53 AM +00:00 EPPageData:1049439:no__CatalogContent
00007538787A3FD0 0.77kb 0 12:00:00 2/16/2024 7:52:53 AM +00:00 EPPageData:1029729:da__CatalogContent
00007538787A6B48 0.77kb 0 12:00:00 2/16/2024 7:52:53 AM +00:00 EPPageData:1029731:da__CatalogContent
00007538787A74C0 0.77kb 0 12:00:00 2/16/2024 6:21:34 AM +00:00 EPPageData:690644:en__CatalogContent
00007538787A9CC8 0.78kb 0 12:00:00 2/16/2024 5:43:57 AM +00:00 EPPageData:181410:cs-cz__CatalogContent
00007538787ACDD8 0.82kb 0 12:00:00 2/16/2024 2:17:38 PM +00:00 EPPageData:1343746__CatalogContent
00007538787ACFF8 0.83kb 0 12:00:00 2/16/2024 2:17:25 PM +00:00 EPPageData:1343746:en__CatalogContent
00007538787AE658 0.77kb 0 12:00:00 2/16/2024 2:59:37 PM +00:00 EPPageData:1350160:da__CatalogContent
00007538787AE768 0.77kb 0 12:00:00 2/16/2024 2:59:37 PM +00:00 EPPageData:1350162:da__CatalogContent
00007538787AEA98 0.39kb 0 00:00:00 2/16/2024 2:17:38 PM +00:00 EPiAnc:ContentAssetAware1343745__CatalogContent
00007538787AF058 0.77kb 0 12:00:00 2/16/2024 2:59:37 PM +00:00 EPPageData:1347560:da__CatalogContent
00007538787B29A0 0.77kb 0 12:00:00 2/16/2024 2:17:07 PM +00:00 EPPageData:1329806:da__CatalogContent
00007538787B2E68 0.77kb 0 12:00:00 2/16/2024 2:17:07 PM +00:00 EPPageData:1329808:da__CatalogContent
00007538787B31E8 0.77kb 0 12:00:00 2/16/2024 2:17:07 PM +00:00 EPPageData:1329810:da__CatalogContent
ただし、スケジュールされたジョブによってロードされるコンテンツのスライド有効期限タイムアウトのデフォルト値は 1 分であるため、これは本来の値ではありません。つまり、一度ロードすれば完了するアイテムとみなされます。 間違えて12時間に設定してしまったのでしょうか? いいえ
タイムアウトは 600.000.000 ティック (60 秒) に設定されており、これがデフォルト値です。
私はかなり長い間これに髪を引っ張ってきました。 キャッシュ エントリがスケジュールされたジョブによって追加されたのではなく、スケジュールされたジョブの制限の影響を受けない他の方法によって追加された場合はどうなるでしょうか? つまり、インデックス作成ジョブの検索に関する顧客の発言に騙されたのです。 それは単に同じ問題の被害者でした。 キャッシュエントリへの最後のアクセスをリセットしていましたが、それだけです。
もう少し掘り下げてみましょう。 Windbg は非常に強力ですが、特定のコンテンツをキャッシュにロードするコードがどこにあるのかを知ることはできません (現行犯で捕まえない限りわかりません)。 したがって、それを知る唯一の方法は、周囲を見回して不審な電話がないか確認することです。 IContentLoader.GetItems または IContentLoader.GetChildren 。 私の同僚は顧客と協力してソース コードを入手し、さらに詳しく調査しました。
私たちにとって幸いなことに、お客様は、以前の問題で構築を支援したカスタムビルドの検索インデクサーを持っており、それが検索で表示されました。 GetItems。 それが犯人かもしれないと私は思いました。 ジョブ自体は問題ありませんが、間違ったデータが与えられたため、コンテンツをインデックスにロードし続けます。
私の仮説が正しければ、次のことが真実であるはずです。
- インデックス作成ジョブが実行されているかどうかに関係なく、アプリのメモリ使用量は 25 GB まで増加します。 そしてそれはあまり変動することなくそこに留まります
- たくさん並んでいます
tblFindIndexQueue
どちらも正しいことが判明しました。400 万行を超える行がありました。 tblFindIndexQueue、これは 24 時間にわたるアプリのメモリ消費量です

コンテンツ読み込みのソースが判明したら、修正は非常に簡単でした。 私たち側でできることの 1 つは、イベント駆動型インデクサーによってロードされたコンテンツのキャッシュ時間を短縮することです。 メモリ使用量を大幅に改善する FIND-12436 の修正が含まれる Find 16.2.0 にアップグレードする必要があります。
物語の教訓:
- 私はワーカホリックです。 週末は絶対に仕事をすべきではありませんが、心が最もクリアなときなので、必要な場合もあります。
- 見続ける。 しかし、いつものように、いつ諦めて敗北を認めるかを知ってください
- 休憩を取る。 ロング、ショート。 心をリフレッシュして、さまざまな角度から見てみましょう。
- スライディング キャッシュの有効期限は、まったく予期しないものになる可能性があります。 コンテンツがすでにキャッシュ内にあり、スライド式有効期限が長い場合、キャッシュ ヒット (経由)
ISynchronizedObjectInstanceCache.ReadThrough短いスライド有効期限でコンテンツを取得する場合、その値は変更されず、最終アクセス時刻が更新されるだけであり、その逆も同様です)
#高いメモリ使用量の謎を解く