問題タブ [memory-fragmentation]

StringBuildersでSystemOutOfMemory例外が発生します。RAMの不足によるものではないので、メモリの断片化だと思います。

〜200個のStringBuilerオブジェクトがあります。これらはすべて定期的に再利用されます（strBldr.clear（）を使用）。これにより、私のシステムはメモリをかなりひどく断片化するようです。どうすればこれを解決できますか？

ありがとう ：）

編集：

ここにいくつかのデータがあります：

input＆stringBuilderの最大記録サイズ：4146698。

Avarageが再起動したstringBuilders/秒：> 120（おそらく>> 120）

入力の長さ@最初のエラー：16 972（文字列）

StringBuilderの長さ@最初のエラー：16

新しいstringBuilderが作成された回数@最初のエラー：〜32500

合計RAM使用量@最初のエラー637448K

32 ビット マシンでは、各プロセスが 4GB の仮想空間を取得します。この場合、断片化による問題が発生するのではないかと心配することができます。しかし、64 ビット マシンの場合、理論的には巨大なアドレス指定可能な仮想メモリがあるのに、64 ビット マシンでメモリの断片化がまだ問題になるのはなぜでしょうか?

数週間、SharePoint 2007 (多くのカスタマイズを行った公開イントラネット) の WFE (SP 2 および Win 2003 32 ビット サーバー) で OutOfMemory の問題に取り組んでいました。クラッシュしたメモリ ダンプを受け取った後、メモリの断片化の問題があることがわかりました。ダンプ分析には、次の 2 つのツールを使用します。DiagDebug と Windbg と sos.dll です。

結果: 96,74% 空きメモリの断片化

DebugDiag (メモリ不足アナライザー)

DebugDiag (SharePoint アナライザー)

それでは、メモリの断片化の原因を理解したいと思います。あなたが私を助けてくれることを願っています。これらは、正しい情報を得るために私が行った手順です。

sos.dll を使用した Windbg

!アドレスまとめ

全体的に十分な空きメモリ (742928 KB) があるようですが、最大の空きチャンクには 24192 KB しかありません。繰り返しますが、メモリの断片化を解放してください!

!スレッド

!eeheap -gc

!dumpheap (heap1 抽出)

• 0a060038 000e1a98 16 フリー
• 0a060048 793042f4 4096
• 0a061048 000e1a98 16 フリー
• 0a061058 793042f4 528
• 0a061268 000e1a98 16 フリー
• 0a061278 793042f4 4096
• 0a062278 000e1a98 16 フリー
• 0a062288 793042f4 5112
• 0a063680 000e1a98 16 フリー
• 0a063690 793042f4 4096
• 0a064690 000e1a98 16 フリー
• 0a0646a0 793042f4 4096
• 0a0656a0 000e1a98 16 フリー
• 0a0656b0 793042f4 5112
• 0a066aa8 000e1a98 16 フリー
• 0a066ab8 793042f4 4096
• 0a067ab8 000e1a98 16 フリー
• 0a067ac8 793042f4 4096
• 0a068ac8 000e1a98 16 フリー
• 0a068ad8 793042f4 4096
• 0a069ad8 793042f4 528
• 0a069ce8 000e1a98 16 フリー
• 0a069cf8 793042f4 528
• 0a069f08 793042f4 528
• 0a06a118 000e1a98 16 フリー
• 0a06a128 793042f4 528
• 0a06a338 000e1a98 260096 無料
• 0a0a9b38 793042f4 4096
• 0a0aab38 000e1a98 16 フリー
• 0a0aab48 793042f4 5784
• 0a0ac1e0 000e1a98 16 フリー
• 0a0ac1f0 793042f4 4096
• 0a0ad1f0 000e1a98 16 フリー
• 0a0ad200 793042f4 528
• 0a0ad410 000e1a98 16 フリー
• 0a0ad420 793042f4 4096
• 0a0ae420 000e1a98 16 フリー
• 0a0ae430 793042f4 528
• 0a0ae640 000e1a98 16 フリー
• 0a0ae650 793042f4 4096
• 0a0af650 000e1a98 16 フリー
• 0a0af660 793042f4 528
• 0a0af870 000e1a98 16 フリー
• 0a0af880 793042f4 528
• 0a0afa90 000e1a98 131120 無料
• 0a0cfac0 793042f4 528
• 0a0cfcd0 000e1a98 16 フリー
• 0a0cfce0 793042f4 4096
• 0a0d0ce0 000e1a98 16 フリー
• 0a0d0cf0 793042f4 528
• 0a0d0f00 000e1a98 16 フリー
• 0a0d0f10 793042f4 528
• 0a0d1120 000e1a98 16 フリー
• 0a0d1130 793042f4 528
• 0a0d1340 000e1a98 16 フリー
• 0a0d1350 793042f4 4096
• 0a0d2350 000e1a98 16 フリー
• 0a0d2360 793042f4 5784
• 0a0d39f8 000e1a98 16 フリー
• 0a0d3a08 793042f4 4096
• 0a0d4a08 000e1a98 348200 無料
• 0a129a30 793042f4 528
• 0a129c40 000e1a98 16 フリー
• 0a129c50 793042f4 528
• 0a129e60 000e1a98 361224 無料
• 0a182168 793042f4 528
• 0a182378 000e1a98 16 フリー
• 0a182388 793042f4 7016
• 0a183ef0 000e1a98 16 フリー
• 0a183f00 793042f4 7016
• ...
• 63859d80 14762 413336 System.Xml.XmlElement
• 6385a090 12103 435708 System.Xml.XmlName
• 79332b54 21020 504480 System.Collections.ArrayList
• 6385798c 32932 658640 System.Xml.NameTable+エントリ
• 6385c76c 35215 704300 System.Xml.XmlAttribute
• 79331754 505 706416 System.Char[]
• 7932dd5c 12751 714056 System.Reflection.RuntimePropertyInfo
• 6385a284 36665 733300 System.Xml.XmlText
• 79332cc0 5530 791644 System.Int32[]
• 7932fde0 22824 1278144 System.Reflection.RuntimeMethodInfo
• 79333274 6758 1733808 System.Collections.Hashtable+bucket[]
• 793042f4 54360 5051132 System.Object[]
• 79333594 4772 29304312 System.Byte[]
• 79330b24 225539 ​​33121896 System.String
• 000e1a98 239 72089072 無料
• 合計 711343 個のオブジェクト
• 0.5 MB を超える断片化されたブロック:
• Addr Size に続く 4331b1d8 14.8MB 441e8270 System.Threading.Overlapped

「無料」セグメント間のいくつかのアドレスを調べましたが、残念ながら、問題を引き起こしたソースに関する情報は見つかりませんでした。

!do 0a182388

!gcroot 0a182388

!gcroot 0a129a30 ... スキャン スレッド 64 OSTHread 6420

!gcroot 0a061278 ... DOMAIN(000DD1B8):HANDLE(Pinned):1fb13f0:Root:0a061278(System.Object[])

!gchandles

DebugDiag SharePoint 分析で、いくつかの未処理の SPWeb オブジェクトが報告されました。ここで原因を見つけようとしています...レポート：「未処理のSPWebオブジェクト0x02701168は、破棄されたまたは無効なSPRequestオブジェクトを参照しています：0x0270137c」

!do 0x02701168

!gcroot 0x02701168

MS 破棄チェッカーでも問題は見つかりませんでした。

そのため、メモリの断片化を引き起こす (カスタム) コンポーネントを見つけるためにさらに進む方法がわかりません。フラグメンテーションを引き起こす可能性のあるコンポーネント（ウイルス対策、キャッシュなど）のヒント、ツールの提案、またはチェックリストを教えていただければ幸いです。この問題は本番環境でのみ発生し、現在私たちが行っている唯一のことは iisreset です - 時には 1 日 5 回…</p>

よろしくお願いいたします。

アントン

コマンド ラインで pid を入力し、予約されていない最大の連続アドレス空間を取得したいと考えています。何か案は？

64 ビット RHEL 5.4 で実行されている 32 ビット アプリは、しばらく (たとえば 24 時間) 実行した後、異常終了します。その時のメモリ使用量は最大で 2.5 GB ですが、メモリ エラーが発生します。アプリのメモリ空間が断片化されているため、大きなファイルの mmap に失敗していると考えられます。私は本番サーバーに行って、その理論をテストしたかったのです。

malloc()/new を使用して、256KB のメモリを変数 m に割り当てたいと考えています。次に、m を使用して、文字列や数値などのデータを格納します。私の問題は、データを m に保存して取得する方法です。

たとえば、int 123456 をオフセット 0 から 3 に格納し、変数 x に読み込むにはどうすればよいでしょうか? または、「David」文字列をオフセット 4 から 8 (または \0 で 9) に保存してから、変数 s に取得しますか?

C++ を使用して作成された大規模なサーバー アプリケーションに取り組んでいます。このサーバーは、おそらく数か月間、再起動せずに実行する必要があります。時間の経過とともにメモリ消費量が増加するため、断片化はすでに疑わしい問題です。これまでの測定は、プライベート バイトと仮想バイトを比較し、これら 2 つの数値の違いを分析することでした。

断片化に対する私の一般的なアプローチは、分析に任せることです。一般的なパフォーマンスやメモリの最適化など、他のことについても同じように考えています。分析と証明で変更をバックアップする必要があります。

コードのレビューやディスカッション中に、メモリの断片化が最初に発生する問題の 1 つであることによく気づきます。現在、それに対する大きな恐怖があり、事前に「断片化を防ぐ」ための大きなイニシアチブがあるようです. メモリの断片化の問題を軽減または防止するのに有利と思われるコードの変更が要求されます。これらは私には時期尚早の最適化のように見えるので、すぐにこれらに反対する傾向があります。コードのクリーンさ/読みやすさ/保守性などを犠牲にします。これらの変化を満たすために。

たとえば、次のコードを見てください。

上記で、stringstream がここで行う割り当ての数は定義されていません。4 つの割り当て、または 1 つの割り当てである可能性があります。したがって、それだけに基づいて最適化することはできませんが、一般的なコンセンサスは、固定バッファーを使用するか、何らかの方法でコードを変更して、潜在的に少ない割り当てを使用することです。ここで文字列ストリームがメモリの問題の大きな原因になっているとは思えませんが、間違っているかもしれません。

上記のコードに対する一般的な改善提案は、次の行に沿っています。

また、可能な限りスタック オーバー ヒープを使用するという大きな推進力もあります。

このようにメモリの断片化を先取りすることは可能ですか、それともこれは単なる誤った安心感ですか?

まとめ：

本来よりも多くのメモリを消費するアプリケーションがあります (予想量の約 250%) が、メモリ リークを見つけることができないようです。同じ関数 (多くの割り当てを行う) を呼び出すと、メモリ使用量がある程度増加し続け、その後は変化せず、そこにとどまります。

プログラムの詳細:

アプリケーションは、四分木データ構造を使用して「ポイント」を保存します。メモリに格納するポイントの最大数 (キャッシュ サイズ) を指定することができます。「ポイント」は「PointBuckets」(クワッドツリーのリーフ ノードにリンクされたポイントの配列) に格納され、クワッドツリー内のポイントの最大総数に達すると、シリアル化されて一時ファイルに保存され、次のときに取得されます。必要です。これはすべてうまくいくようです。

ファイルが読み込まれると、新しい Quadtree が作成され、古いものが存在する場合は削除され、ファイルからポイントが読み取られ、Quadtree に 1 つずつ挿入されます。ノード分割などでバケットが作成および削除されると、大量のメモリ割り当てが発生します。

症状：

300MB のメモリを 1 回使用すると予想されるファイルをロードすると、予想される量のメモリが消費されます。すべて良い。同じファイルを何度もロードし続けると、メモリ使用量が増加し続けます (Linux の一番上の RES 列を見ています) 約 700MB まで増加します。これは、メモリ リークを示している可能性があります。ただし、ファイルをロードし続けると、メモリ消費量は 700MB のままです。

別のこと: valgrind massif を使用してメモリ使用量を確認すると、常に予想される制限内に収まっています。たとえば、キャッシュ サイズを 1.5 GB に指定してプログラムを単独で実行すると、最終的に 4 GB のメモリが消費されます。Massif で実行すると、常に 2GB 未満に留まり、生成されたグラフでは、実際には予想される 1.5GB を超えて割り当てられていないことがわかります。私の素朴な仮定は、massif が何らかの方法で断片化を防止するカスタム メモリ プールを使用するために発生するということです。

それで、ここで何が起こっていると思いますか？メモリの断片化である場合、この問題を解決するにはどのような解決策を探す必要がありますか?

大量の MSMQ キュー (現時点では約 10000) から読み取るアプリケーションがあります。queue.BeginPeekUInt32.MaxValue タイムアウトを使用して、キューからメッセージを受信します。メッセージがキューに表示されたら、それを処理してqueue.BeginPeek再度呼び出します。そのため、すべてのキューをリッスンしますが、メッセージ処理はスレッド プールで行われます。

メモリ使用量がゆっくりと増加していることに気付きました (2 週間の作業で 200 MB から 800 MB に増加します)。ダンプ ファイルを調べたところ、多くのフリー オブジェクトが含まれる典型的なヒープ フラグメンテーションの図が表示されます (サイズが数メガバイトのものもあります)。そして、穴の間にピンで留められたオブジェクトがあります。

これは、固定されたオブジェクトを作成するアンマネージ コードの呼び出しを操作する場合によくある状況のようです。しかし、私はインターネットで解決策を見つけられませんでした。

では、.NET のメモリ管理は非常に純粋なため、そのような単純なシナリオでさえ完了できないのでしょうか。

編集：サンプルアプリケーションでいくつかの調査を行いました。固定されたオブジェクト間のホール (フリー メモリ ゾーン、いわゆるフリー オブジェクト) は、新しいオブジェクトにメモリを割り当てるときに GC によって再利用されます。しかし、私の実稼働アプリケーションでは、固定されたオブジェクトは長生きし、最終的にそれらの間に穴が開いた第 2 世代で表示されます (GC は世代を分離する境界を移動するため)。通常の寿命の長いオブジェクトがほとんどないため、第 2 世代のダンプ ファイルにこの穴が見られます。

そのため、アプリケーションのメモリ消費量は 10000* (穴の平均サイズ) まで増加する可能性があります。(10000 は、将来的に増加する可能性のあるキューの数です)。現時点では、これを修正する方法がわかりません。唯一の方法は、時々アプリケーションを再起動することです。

繰り返しになりますが、なぜ .NET にはピン留めされたオブジェクト用の個別のヒープがないのでしょうか? （たぶんこれは初心者の質問です）。現時点では、アンマネージ コードで動作する非同期操作を呼び出すと、メモリの問題が発生する可能性があることがわかります。

メモリを割り当てようとしていますが、「メモリ不足」というエラーが発生することがあります。cudaMemGetInfoは、私が必要とするより多くのメモリが利用可能であると言います。だから、メモリの断片化の問題。この問題を解決することは可能ですか? 要素を 1 つずつメモリに配置するのではなく、メモリに配置できるいくつかのピースに断片化することは可能ですか?