Vermeiden von OutOfMemoryException bei großen, schnellen und häufigen Speicherzuordnungen in C #
Unsere Anwendung ordnet kontinuierlich Arrays für große Datenmengen (z. B. zehn bis Hunderte von Megabyte) zu, die nur kurze Zeit gültig sind, bevor sie verworfen werden.
Wenn Sie dies auf einfache Weise tun, kann dies zu einer Fragmentierung des Heapspeichers großer Objekte führen, wodurch die Anwendung möglicherweise mit einer OutOfMemoryException abstürzt, obwohl die Größe der aktuell aktiven Objekte nicht übermäßig groß ist.
Eine Möglichkeit, wie wir dies in der Vergangenheit erfolgreich bewältigt haben, besteht darin, die Arrays aufzuteilen, um sicherzustellen, dass sie nicht auf dem LOH landen. Ziel ist es, eine Fragmentierung zu vermeiden, indem der Speicher vom Garbage Collector komprimiert wird.
Unsere neueste Anwendung verarbeitet mehr Daten als zuvor und überträgt diese serialisierten Daten sehr häufig zwischen Add-Ins, die entweder in separaten AppDomains oder in separaten Prozessen gehostet werden. Wir haben den gleichen Ansatz wie zuvor gewählt, um sicherzustellen, dass unser Speicher immer blockiert ist, und um große Objektheapzuordnungen zu vermeiden.
Wir haben jedoch ein Add-In, das in einem externen 32-Bit-Prozess gehostet werden muss (da unsere Hauptanwendung 64-Bit ist und das Add-In eine 32-Bit-Bibliothek verwenden muss). Unter besonders hoher Last, wenn viele SOH-Speicher-Chunks kurz darauf schnell zugewiesen und verworfen werden, hat selbst unser Chunking-Ansatz nicht ausgereicht, um unser 32-Bit-Add-In zu speichern, und es stürzt mit einer OutOfMemoryException ab.
Verwenden von WinDbg zu dem Zeitpunkt, zu dem eine OutOfMemoryException auftritt,!heapstat -inclUnrooted
zeigt dies:
Heap Gen0 Gen1 Gen2 LOH
Heap0 24612 4166452 228499692 9757136
Free space: Percentage
Heap0 12 12 4636044 12848SOH: 1% LOH: 0%
Unrooted objects: Percentage
Heap0 72 0 5488 0SOH: 0% LOH: 0%
!dumpheap -stat
Zeig das:
-- SNIP --
79b56c28 3085 435356 System.Object[]
79b8ebd4 1 1048592 System.UInt16[]
79b9f9ac 26880 1301812 System.String
002f7a60 34 4648916 Free
79ba4944 6128 87366192 System.Byte[]
79b8ef28 17195 145981324 System.Double[]
Total 97166 objects
Fragmented blocks larger than 0.5 MB:
Addr Size Followed by
18c91000 3.7MB 19042c7c System.Threading.OverlappedData
Diese sagen mir, dass unsere Speichernutzung nicht übermäßig ist und unser großer Objektheap wie erwartet sehr klein ist (daher haben wir es hier definitiv nicht mit einer Fragmentierung großer Objektheaps zu tun).
Jedoch,!eeheap -gc
zeigt dies:
Number of GC Heaps: 1
generation 0 starts at 0x7452b504
generation 1 starts at 0x741321d0
generation 2 starts at 0x01f91000
ephemeral segment allocation context: none
segment begin allocated size
01f90000 01f91000 02c578d0 0xcc68d0(13396176)
3cb10000 3cb11000 3d5228b0 0xa118b0(10557616)
3ece0000 3ece1000 3fc2ef48 0xf4df48(16047944)
3db10000 3db11000 3e8fc8f8 0xdeb8f8(14596344)
42e20000 42e21000 4393e1f8 0xb1d1f8(11653624)
18c90000 18c91000 19c53210 0xfc2210(16523792)
14c90000 14c91000 15c85c78 0xff4c78(16731256)
15c90000 15c91000 168b2870 0xc21870(12720240)
16c90000 16c91000 17690744 0x9ff744(10483524)
5c0c0000 5c0c1000 5d05381c 0xf9281c(16328732)
69c80000 69c81000 6a88bc88 0xc0ac88(12627080)
6b2d0000 6b2d1000 6b83e8a0 0x56d8a0(5691552)
6c2d0000 6c2d1000 6d0f2608 0xe21608(14816776)
6d2d0000 6d2d1000 6defc67c 0xc2b67c(12760700)
6e2d0000 6e2d1000 6ee7f304 0xbae304(12247812)
70000000 70001000 70bfb41c 0xbfa41c(12559388)
71ca0000 71ca1000 72893440 0xbf2440(12526656)
73b40000 73b41000 74531528 0x9f0528(10421544)
Large object heap starts at 0x02f91000
segment begin allocated size
02f90000 02f91000 038df1d0 0x94e1d0(9757136)
Total Size: Size: 0xe737614 (242447892) bytes.
------------------------------
GC Heap Size: Size: 0xe737614 (242447892) bytes.
Was mir hier auffällt, ist, dass unser letztes SOH-Heap-Segment bei 0x73b41000 beginnt, was genau an der Grenze unseres verfügbaren Speichers in unserem 32-Bit-Add-In liegt.
Wenn ich das richtig lese, scheint unser Problem zu sein, dass unser virtueller Speicher mit verwalteten Heap-Segmenten fragmentiert ist.
Ich denke meine Fragen wären hier:
Ist meine Analyse korrekt?Ist unser Ansatz zur Vermeidung von LOH-Fragmentierung durch Chunking sinnvoll?Gibt es eine gute Strategie, um die Speicherfragmentierung zu vermeiden, die wir jetzt zu sehen scheinen?Die naheliegendste Antwort, die ich mir vorstellen kann, ist, unsere Speicherbereiche zusammenzufassen und wiederzuverwenden. Möglicherweise ist dies möglich, aber ich würde es lieber vermeiden, da wir diesen Teil unseres Gedächtnisses effektiv selbst verwalten müssen.