Один из наших небольших win-сервисов PRD неожиданно взлетел до 80+ ГБ памяти на несколько часов, а затем вышел из строя и стабилизировался на 6+ ГБ памяти, обычно он использует только менее 200 МБ. Я взял дамп памяти во время 6+ ГБ, и перезапустил сервер, все вернуться к нормальной жизни. Я исследую, почему он взлетел до такой высоты и почему он стабильно стоит на 6+ ГБ.
Я обнаружил, что это проблема неуправляемой утечки памяти, поскольку куча CLR мала:
0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x000000910083ff20
generation 1 starts at 0x00000091007caba0
generation 2 starts at 0x0000009100001000
ephemeral segment allocation context: none
segment begin allocated size
0000009100000000 0000009100001000 00000091029691f0 0x29681f0(43418096)
Large object heap starts at 0x0000009110001000
segment begin allocated size
0000009110000000 0000009110001000 000000911013dcb8 0x13ccb8(1297592)
Total Size: Size: 0x2aa4ea8 (44715688) bytes.
------------------------------
***GC Heap Size: Size: 0x2aa4ea8 (44715688) bytes.***
Но Сводка кучи высока, более подозрительно, что количество блокировок велико :
0:000> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x45d65d36d8f8b642
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
**000000917aa90000 00000002 6718396 6682116 6718196 71860 5580 419 2 93 LFH**
000000917a850000 00008000 64 4 64 2 1 1 0 0
000000917acd0000 00001002 1280 88 1080 15 7 2 0 0 LFH
000000917ac90000 00001002 1280 108 1080 24 8 2 0 0 LFH
000000917b160000 00001002 1280 124 1080 7 10 2 0 0 LFH
000000917b310000 00041002 60 8 60 5 1 1 0 0
000000917bd40000 00041002 260 36 60 4 3 1 0 0 LFH
0000009118080000 00001002 1084 1024 1084 1021 2 1 0 0
-------------------------------------------------------------------------------------
0:000> !heap -stat -h 000000917aa90000
heap @ 000000917aa90000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
2d0b0 373e - 9b845aa0 (39.37)
10d1 41962 - 44eed902 (17.45)
ddc8 373e - 2fdbae70 (12.12)
7ab8 373e - 1a7b4090 (6.70)
7168 373e - 1878cf30 (6.20)
29d1 6e6b - 1209485b (4.57)
35d1 372d - b995cbd (2.94)
31d1 372d - abca8bd (2.72)
12d1 6e5a - 81c6b7a (2.05)
21d1 3746 - 74d2626 (1.85)
fd1 6e6c - 6d27a2c (1.73)
1cd1 372d - 635f7bd (1.57)
40 22b52 - 8ad480 (0.14)
100 6ef7 - 6ef700 (0.11)
200 374f - 6e9e00 (0.11)
c3500 5 - 3d0900 (0.06)
80 6edb - 376d80 (0.05)
d8 374e - 2ea9d0 (0.05)
249f18 1 - 249f18 (0.04)
90 3792 - 1f4220 (0.03)
Тогда я сделал !heap -flt s 2d0b0
Я не могу сделать !heap -p -a, чтобы увидеть стек, потому что у меня нет включенных флагов в PRD.
Вместо этого я пытаюсь сделать dc 00000092b7088bb0 L200, чтобы угадать основание на строковом значении. Ничего осмысленного в первом патроне (2d0b0 373e - 9b845aa0 (39.37) Но во втором патроне ( 10d1 41962 - 44eed902 (17.45)) я нашел что-то вроде
00000092`b70b0250 00000000 00000000 44440000 4e4f4d2d ..........DD-MON
00000092`b70b0260 0052522d 00000000 00000000 00000000 -RR.............
00000092`b70b0270 00000000 00000000 00000000 00000000 ................
00000092`b70b0280 00000000 00000000 00000000 00000000 ................
00000092`b70b0290 00000000 48480000 2e494d2e 46585353 ......HH.MI.SSXF
00000092`b70b02a0 4d412046 00000000 00000000 00000000 F AM............
00000092`b70b02b0 00000000 00000000 00000000 00000000 ................
00000092`b70b02c0 00000000 44440000 4e4f4d2d 2052522d ......DD-MON-RR
00000092`b70b02d0 4d2e4848 53532e49 20464658 00004d41 HH.MI.SSXFF AM..
00000092`b70b02e0 00000000 00000000 00000000 00000000 ................
00000092`b70b02f0 00000000 00000000 00000000 00000000 ................
00000092`b70b0300 00000000 00000000 00000000 00000000 ................
00000092`b70b0310 00000000 48480000 2e494d2e 46585353 ......HH.MI.SSXF
00000092`b70b0320 4d412046 525a5420 00000000 00000000 F AM TZR........
00000092`b70b0330 00000000 00000000 00000000 00000000 ................
00000092`b70b0340 00000000 00000000 00000000 00000000 ................
00000092`b70b0350 00000000 00000000 44440000 4e4f4d2d ..........DD-MON
00000092`b70b0360 2052522d 4d2e4848 53532e49 20464658 -RR HH.MI.SSXFF
00000092`b70b0370 54204d41 0000525a 00000000 00000000 AM TZR..........
Похоже, строка формата даты и времени в Oracle Database Query. И мы используем Oracle, и мне трудно поверить, что мы пропускаем соединения оракула, потому что эта небольшая служба работала в течение многих лет, и это происходит впервые.
Вот как далеко я могу сейчас пройти.
Извините за длинный вопрос и спасибо, что потратили время на чтение
Подводя итог моему вопросу:
- что означает столбец счетчика блокировок! Heap -s, который выглядит как
индикатор проблемы, где я могу продолжать копать, пожалуйста, укажите мне
направление или блог, который я могу прочитать.
- Являются ли эти строки необработанных данных еще одним звонком вместо вас? У вас когда-нибудь была похожая проблема?
- Мы используем много .net удаленного взаимодействия. Я знаю, что это старо, и я никогда не погружался в это глубоко. Может ли это быть фактором этой проблемы?
- Я ничего не могу сделать в PRD, и я не могу воспроизвести эту проблему в DEV / TEST, есть ли другое направление, которое я могу выбрать?