1

We have this application running as Windows Service. I was checking memory usage of it using task manager and perfmon and I noticed that from time to time it allocates big chunk of memory, which is not being released for a long period of time. Anyway, I've started checking process dumps, and during LOH analysis I noticed this small objects which for some reason are being placed on LOH. Each of free memory chunk is 24 bytes - how it is possible, since only objects larger than 85Kb may end up on LOH? Can this small chunk, when it not 'freed' can cause memory leak? 

0:000> !EEHeap -gc
Number of GC Heaps: 1
      generation 0 starts at 0x0000000001520400
      generation 1 starts at 0x000000000148b8e0
      generation 2 starts at 0x00000000010b1000
      ephemeral segment allocation context: none
               segment             begin         allocated  size
      00000000010b0000  00000000010b1000  00000000016eb568  0x63a568(6530408)
      Large object heap starts at 0x00000000110b1000
               segment             begin         allocated  size
      00000000110b0000  00000000110b1000  0000000016e74bf0  0x5dc3bf0(98319344)
      Total Size:              Size: 0x63fe158 (104849752) bytes.
      ------------------------------
      GC Heap Size:    Size: 0x63fe158 (104849752) bytes.
      0:000> !dumpheap 00000000110b1000  0000000016e74bf0  
               Address               MT     Size
      00000000110b1000 000000000057c1b0       24 Free
      00000000110b1018 000007feedc1ae68     8192     
      00000000110b3018 000000000057c1b0       24 Free
      00000000110b3030 000007feedc1ae68     1056     
      00000000110b3450 000000000057c1b0     7136 Free
      00000000110b5030 000007feedc1ae68     8192     
      00000000110b7030 000000000057c1b0       24 Free
      00000000110b7048 000007feedc1ae68    16352     
      00000000110bb028 000000000057c1b0       24 Free
      00000000110bb040 000007feedc1ae68    32672     
      00000000110c2fe0 000000000057c1b0       24 Free
      00000000110c2ff8 000007feedc1ae68     2080     
      00000000110c3818 000000000057c1b0     6112 Free
      00000000110c4ff8 000007feedc1ae68     4128     
      00000000110c6018 000000000057c1b0   393312 Free
      0000000011126078 000007feedc20bb0   524312     
      00000000111a6090 000000000057c1b0       24 Free
      00000000111a60a8 000007feedc16960  1438960     
      0000000011305598 000000000057c1b0       24 Free
      00000000113055b0 000007feedc20bb0  1048600     
      00000000114055c8 000007feedc16960  1439352     
      0000000011564c40 000000000057c1b0       24 Free
      0000000011564c58 000007feedc1b318  1449800     
      00000000116c6ba0 000000000057c1b0       24 Free
      00000000116c6bb8 000000000057c1b0    70752 Free
      00000000116d8018 000007feedc1ae68    65312     
      00000000116e7f38 000007feedc20bb0   722704     
      0000000011798648 000000000057c1b0       24 Free
      0000000011798660 000007feedc1b318  1449792     
      00000000118fa5a0 000000000057c1b0       24 Free
      00000000118fa5b8 000007feedc16960  1437664     
      0000000011a59598 000000000057c1b0       24 Free
      0000000011a595b0 000007feedc1b318  1450248     
      0000000011bbb6b8 000000000057c1b0       24 Free
      0000000011bbb6d0 000007feedc20bb0   364840     
      0000000011c147f8 000000000057c1b0       24 Free
      0000000011c14810 000007feedc20bb0   364840     
      0000000011c6d938 000000000057c1b0       24 Free
      0000000011c6d950 000007feedc20bb0   131096     
      0000000011c8d968 000000000057c1b0       24 Free
      0000000011c8d980 000007feedc20bb0   262168     
      0000000011ccd998 000000000057c1b0       24 Free
      0000000011ccd9b0 000007feedc20bb0   524312     
      0000000011d4d9c8 000000000057c1b0       24 Free
      0000000011d4d9e0 000007feedc20bb0   364840     
      0000000011da6b08 000000000057c1b0       24 Free
      0000000011da6b20 000007feedc16960   544480     
      0000000011e2ba00 000000000057c1b0       24 Free
      0000000011e2ba18 000007feedc1b318   544480     
      0000000011eb08f8 000000000057c1b0       24 Free
      0000000011eb0910 000007feedc20bb0   272256     
      0000000011ef3090 000000000057c1b0       24 Free
      0000000011ef30a8 000007feedc20bb0   131096     
      0000000011f130c0 000000000057c1b0       24 Free
      0000000011f130d8 000007feedc20bb0   262168     
      0000000011f530f0 000000000057c1b0       24 Free
      0000000011f53108 000000000057c1b0   269104 Free
      0000000011f94c38 000007feedc1ae68    16352     
      0000000011f98c18 000007feedc20bb0   524312     
      0000000012018c30 000000000057c1b0       24 Free
      0000000012018c48 000000000057c1b0   196152 Free
      0000000012048a80 000007feedc1ae68     8224     
      000000001204aaa0 000007feedc16960  1437664     
      00000000121a9a80 000007feedc20bb0   272256     
      00000000121ec200 000000000057c1b0       24 Free
      00000000121ec218 000007feedc20bb0   143144     
      000000001220f140 000000000057c1b0       24 Free
      000000001220f158 000007feedc20bb0   143144     
      0000000012232080 000000000057c1b0       24 Free

Can anyone explain this?

Thanks, Marcin

lasjan
  • 71
  • 8
  • 1
    Note that 24 bytes is the minimum object size on x64. I suspect they're gaps left for plug information, but without my copy of @KonradKokosa's Pro .NET Memory Management to hand I can't remember exactly. Check Chapter 9 if you have a copy. – canton7 Aug 14 '19 at 09:11
  • It seems you have LOH fragmentation, it can cause problems on 32 bit systems (like OOM issues). You may have much frequent GEN 2 collections because you need continuous address space to allocate new objects & due to fragmentation, although you may have enough free space, it won't be continuous. I would suggest to dig deeper to find what are those big objects that are being allocated and try to eliminate fragmentation. Easiest way would probably be memory pooling, but it all depends on your specific case. – Michael Aug 14 '19 at 09:29
  • @Michael What evidence do you have that there is LOH fragmentation? That dump looks fairly good to me. – canton7 Aug 14 '19 at 09:35
  • Hi, thanks for replying. Well, altough I'm suspecting LOH fragmentation there seems not to be any pinned object on LOH (instead of required ones, which should be there during app lifecycle). I've check few objects using gcroot and there are no references for them. I think that full GC did not hit yet, maybe threshold was not reached yet? – lasjan Aug 14 '19 at 09:37
  • @lasjan I would still look into few objects in LOH to find what are they? use `!do
    ` on few of them and see what are those (arrays, long strings etc...) ? If you're on .NET 4.5 or higher maybe enable LOH compaction and see if memory footprint is better. In general [LOH fragmentation](https://stackoverflow.com/a/2402627/997668) can be caused by different reasons. Another great tool to see memory footpring is VMMap, I would use that as well to see what's going on there.
     – Michael Aug 14 '19 at 09:53
  • Hi, I checked few of them and they are byte, char arrays and long strings. This service is processing lot of blob data provided by database, so I think it is suitable. GCroot does not point to Domain, which suggest that there are no references to those object (or am I wrog?) – lasjan Aug 14 '19 at 10:43

0 Answers0