Nosso aplicativo aloca continuamente matrizes para grandes quantidades de dados (digamos dezenas a centenas de megabytes) que vivem por um curto período de tempo antes de serem descartados.

Feito ingenuamente, isso pode causar a fragmentação de heap de objeto grande, fazendo com que o aplicativo trave com um OutOfMemoryException, apesar do tamanho dos objetos atualmente ativos não ser excessivo.

Uma forma de gerenciar isso com sucesso no passado é dividir os arrays para garantir que eles não acabem no LOH, a idéia é evitar a fragmentação, permitindo que a memória seja compactada pelo coletor de lixo.

Nosso aplicativo mais recente lida com mais dados do que antes e passa esses dados serializados com muita frequência entre os suplementos hospedados em AppDomains separados ou em processos separados. Adotamos a mesma abordagem de antes, garantindo que nossa memória fosse sempre fragmentada e com muito cuidado para evitar grandes alocações de heap de objeto.

No entanto, temos um add-in que deve ser hospedado em um processo externo de 32 bits (porque nosso aplicativo principal é 64 bits e o add-in deve usar uma biblioteca de 32 bits). Sob carga particularmente pesada, quando muitos fragmentos de memória SOH estão sendo rapidamente alocados e descartados pouco tempo depois, até mesmo nossa abordagem de fragmentação não foi suficiente para salvar nosso suplemento de 32 bits e falha com um OutOfMemoryException.

Usando o WinDbg no momento em que ocorre uma OutOfMemoryException,!heapstat -inclUnrooted mostra isso:

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 mostre isto:

-- 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

Estes me dizem que nosso uso de memória não é excessivo, e nosso heap de objeto grande é muito pequeno como esperado (então definitivamente não estamos lidando com fragmentação de heap de objeto grande aqui).

Contudo,!eeheap -gc mostra isso:

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.

O que mais me impressiona aqui é que o nosso segmento de heap SOH final começa em 0x73b41000, o que está bem no limite de nossa memória disponível em nosso suplemento de 32 bits.

Então, se eu estou lendo isso corretamente, nosso problema parece ser que é a nossa memória virtual tornou-se fragmentada com segmentos de heap gerenciados.

Eu acho que minhas perguntas aqui seriam:

Minha análise está correta?A nossa abordagem para evitar fragmentação LOH usando chunking é razoável?Existe uma boa estratégia para evitar a fragmentação da memória que agora parece estar vendo?

A resposta mais óbvia que posso pensar é agrupar e reutilizar nossos blocos de memória. Isso é potencialmente capaz de fazer, mas é algo que eu prefiro evitar, pois envolve-nos efetivamente gerenciar essa parte da nossa memória nós mesmos.