3

我们的PRD小赢服务之一突然暴涨到80+ GB内存几个小时然后又降下来稳定在6+ GB内存，它通常只使用不到200 MB。我在 6+ GB 时抓取了内存转储，然后重新启动服务器，一切恢复正常。我正在调查为什么它会飙升到这么高，以及为什么它稳定在 6GB 以上。

我发现这是一个非托管内存泄漏问题，因为 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 中启用 gflags。

相反，我正在尝试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 数据库查询日期时间格式字符串。而且我们确实使用 Oracle，我很难相信我们正在泄漏 Oracle 连接，因为这个小服务已经运行了多年，这是第一次发生这种情况。这就是我现在能走多远。

很抱歉这个问题很长，感谢您花时间阅读

总结一下我的问题：

  1. !heap -s 中的锁计数列是什么意思，这看起来像是我可以继续挖掘的问题的指标，请指出我可以阅读的方向或博客。
  2. 那些原始数据字符串是否对您敲响了另一个钟声，而不是 Oracle？你有过类似的问题吗？
  3. 我们确实使用了很多 .net 远程处理。我知道它很旧，我从未深入研究过它。这可能是这个问题的一个因素吗？
  4. 我在 PRD 什么都做不了，我也无法在 DEV/TEST 中重现这个问题，我还有其他方向可以采取吗？
4

0 回答 0