Проблема:
В течение нескольких дней объем памяти будет увеличиваться до тех пор, пока у нее не останется памяти с 32-разрядным приложением, которое может выделить только 3,5 ГБ. Эта программа генерирует отчеты на основе различных ERP, веб-сервисов, FTP, которые отправляют их в различных форматах CSV, SMS и т. Д.
Приложение:
Я использую следующие основные установленные пакеты:
- Hangfire v1.7.10
- Hangfire SqlSever v1.7.10
- SimpleImpersonation v3.0
- CsvHelper v15.0.4
- Dapper v2.0.35
- esendex-do tnet -sdk v3.8
- FastMember v1.5
- FluentFTP v23.3.1
- Microsoft.Owin v4.1
- Newtonsoft. Json v12.0.3
- Serilog v2.9
- Serilog.Sinks.Seq v4.0
- Interop.SageDataObject250 v25 (только для x86)
Это Windows Использование службы. NET Framework v4.7.2, скомпилированный для x86 из-за ссылки на Sage.
Шаги, которые я пытался диагностировать проблема:
Я запустил диспетчер задач в x86 и сгенерировал DMP, используя C: \ Windows \ SysWOW64 \ taskmgr.exe
Я скопировал DMP на мое развитие P C и запускал WinDbg в режиме x86 с помощью команды -debugArch x86
Я выполнил команду .loadby sos clr затем !address -summary, которая дает следующие результаты:
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Heap 26731 c4ece000 ( 3.077 GB) 84.59% 76.93%
<unknown> 962 17b0b000 ( 379.043 MB) 10.18% 9.25%
Free 266 1733e000 ( 371.242 MB) 9.06%
Image 958 8b55000 ( 139.332 MB) 3.74% 3.40%
Stack 171 36c0000 ( 54.750 MB) 1.47% 1.34%
TEB 57 7b000 ( 492.000 kB) 0.01% 0.01%
Other 8 46000 ( 280.000 kB) 0.01% 0.01%
PEB 1 3000 ( 12.000 kB) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 27660 dd421000 ( 3.457 GB) 95.04% 86.43%
MEM_IMAGE 1186 93e7000 ( 147.902 MB) 3.97% 3.61%
MEM_MAPPED 42 24aa000 ( 36.664 MB) 0.98% 0.90%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT 26966 d4334000 ( 3.316 GB) 91.15% 82.89%
MEM_FREE 266 1733e000 ( 371.242 MB) 9.06%
MEM_RESERVE 1922 1497e000 ( 329.492 MB) 8.85% 8.04%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 14073 c60df000 ( 3.095 GB) 85.08% 77.37%
PAGE_EXECUTE_READ 108 6730000 ( 103.188 MB) 2.77% 2.52%
PAGE_READONLY 365 4181000 ( 65.504 MB) 1.76% 1.60%
PAGE_NOACCESS 11990 2ed6000 ( 46.836 MB) 1.26% 1.14%
PAGE_WRITECOPY 270 791000 ( 7.566 MB) 0.20% 0.18%
PAGE_EXECUTE_READWRITE 46 220000 ( 2.125 MB) 0.06% 0.05%
PAGE_READWRITE|PAGE_GUARD 114 11d000 ( 1.113 MB) 0.03% 0.03%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Heap d69a7000 2b8000 ( 2.719 MB)
<unknown> f7f62000 1a88000 ( 26.531 MB)
Free fb230000 3920000 ( 57.125 MB)
Image 70630000 f55000 ( 15.332 MB)
Stack 1c60000 fc000 (1008.000 kB)
TEB e68000 3000 ( 12.000 kB)
Other fecb0000 23000 ( 140.000 kB)
PEB f53000 3000 ( 12.000 kB)
I можно увидеть 3 ГБ в куче, поэтому я запустил !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0xf161e75c
generation 1 starts at 0xf1612484
generation 2 starts at 0x01e11000
ephemeral segment allocation context: none
segment begin allocated size
01e10000 01e11000 02e0ff68 0xffef68(16772968)
2ac00000 2ac01000 2bbfff58 0xffef58(16772952)
e1b70000 e1b71000 e2b6fe3c 0xffee3c(16772668)
dbba0000 dbba1000 dcba0000 0xfff000(16773120)
95e60000 95e61000 96e5ff30 0xffef30(16772912)
c6e40000 c6e41000 c7e3ff70 0xffef70(16772976)
dcba0000 dcba1000 ddb9ff54 0xffef54(16772948)
ddba0000 ddba1000 deb9fccc 0xffeccc(16772300)
dfb70000 dfb71000 e0b6ff2c 0xffef2c(16772908)
e3b40000 e3b41000 e4b3ffac 0xffefac(16773036)
e4b40000 e4b41000 e5b3fec0 0xffeec0(16772800)
f07e0000 f07e1000 f17c17bc 0xfe07bc(16648124)
Large object heap starts at 0x02e11000
segment begin allocated size
02e10000 02e11000 030f2dd8 0x2e1dd8(3022296)
e0b70000 e0b71000 e1af14c0 0xf804c0(16254144)
f3780000 f3781000 f42012a0 0xa802a0(11010720)
Total Size: Size: 0xdcb7248 (231436872) bytes.
------------------------------
GC Heap Size: Size: 0xdcb7248 (231436872) bytes.
231436872 B = 231,436872 МБ Итак, где же остальная часть памяти?
!heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x71f51955
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
01440000 00000002 3221644 3049200 3221588 31845 2238 1075 0 83 LFH
01360000 00001002 1136 88 1080 20 9 2 0 0 LFH
01930000 00001002 1136 132 1080 10 11 2 0 0 LFH
018c0000 00001002 1136 216 1080 4 50 2 0 0 LFH
01e00000 00041002 60 4 60 2 1 1 0 0
04420000 00041002 116 28 60 3 2 1 0 0 LFH
091c0000 00001002 60 12 60 4 2 1 0 0
0a8b0000 00001002 1136 212 1080 73 10 2 0 0 LFH
-----------------------------------------------------------------------------
!dumpheap -stat
7030f850 238 74436 System.Char[]
7030bff0 1279 86972 System.Reflection.RuntimeParameterInfo
01df8d24 218 131672 System.Collections.Generic.Dictionary`2+Entry[[System.Single, mscorlib],[OfficeOpenXml.FontSizeInfo, EPPlus]][]
703109ac 1179 134016 System.Int32[]
7030f378 1416 156412 System.Object[]
7030b680 3479 208740 System.Reflection.RuntimeMethodInfo
6b01c4c8 2 524312 System.Data.DataRow[]
6b01cc24 104 2594016 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][]
70312158 3995 2676025 System.Byte[]
6b01bd4c 80417 5468356 System.Data.DataRow
0145b368 183 6617958 Free
7030f964 406 24582180 System.String[]
7030f0d4 3392330 183245330 System.String
Итак. NET куче не выделено много памяти. Я урезал его, так как список был огромным, но они были снизу самой большой выделенной памятью.
Я не слишком знаком с WinDbg, но я предполагаю, что это утечка памяти кучи?
Итак, единственное, что я могу придумать, для чего могут использоваться нативные кучи и т. Д., Это SimpleImpersonation и Sage из-за того, что он использует COM-объекты?
Если у кого-нибудь есть какие-либо советы или вы можете дать мне sh правильное направление было бы здорово. Спасибо.
Я просмотрел свой код, чтобы убедиться, что все, что имеет IDisposable, использует оператор using.