如何通过 SNMP 从 Cisco 交换机获取每个进程的内存使用情况

网络工程 思科-ios cisco催化剂 snmp
2021-07-18 16:56:07

我正在尝试通过 SNMP 从 Cisco 交换机获取每个进程的内存使用情况。

我发现一篇文章建议您可以减去CISCO-PROCESS-MIB.cpmProcExtMemAllocatedRevCISCO-PROCESS-MIB.cpmProcExtMemFreedRevCisco 进程内存使用量),但这似乎不会产生合理的值。

通常这些值是相同的(导致零),有时释放的大于分配的(导致负数)-尽管我认为这可能与我提取分配的结果和何时释放内存有关我拉了释放的结果。

show processes memory交换机上的输出显示的结果与我通过 SNMP 看到的结果相同(如果分配的释放逻辑正确,则为疯狂值),但它还显示一Holding列,看起来像是我需要的。

    Switch1#show processes memory
    Processor Pool Total:  175382376 Used:   47922940 Free:  127459436
          I/O Pool Total:   16777216 Used:   13591380 Free:    3185836
    Driver te Pool Total:    4194304 Used:         40 Free:    4194264

     PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
       0   0  118863872   66054580   48365728          0          0 *Init*
       0   0      12476 2411645460      12476          0          0 *Sched*
       0   0 3937788032 4286508576    3540184   15562527    1490354 *Dead*
       0   0          0          0     394476          0          0 *MallocLite*
       1   0     348672     187988     175856          0          0 Chunk Manager
       2   0        232        232       4160          0          0 Load Meter
       3   0         76          0       9236          0          0 hulc_entropy_thr
       4   0          0          0      10080          0          0 Connection Mgr
       5   0       4712       4520      11692          0          0 Check heaps
       6   0   16741228   29720504      38796   14834428   22351307 Pool Manager

我找不到任何引用HoldingCISCO-PROCESS-MIB和我已经在互联网上没有运气搜索。

有谁知道如何Holding通过 SNMP获取此字段?

1个回答

我刚刚花了半个小时看这个,我认为没有办法从 SNMP 获得准确的数字。

这是 cpmProcess 中 3 个表中可用的数据(还有更多 OID,但它们似乎没有填充在我正在查看的设备上)

CISCO-PROCESS-MIB::cpmProcessPID.1.5 = Gauge32: 5
CISCO-PROCESS-MIB::cpmProcessName.1.5 = STRING: Pool Manager
CISCO-PROCESS-MIB::cpmProcessuSecs.1.5 = Gauge32: 215 microseconds
CISCO-PROCESS-MIB::cpmProcessTimeCreated.1.5 = Timeticks: (267) 0:00:02.67
CISCO-PROCESS-MIB::cpmProcessAverageUSecs.1.5 = Gauge32: 215 microseconds
CISCO-PROCESS-MIB::cpmProcExtMemAllocated.1.5 = Gauge32: 23223664 bytes
CISCO-PROCESS-MIB::cpmProcExtMemFreed.1.5 = Gauge32: 1784383920 bytes
CISCO-PROCESS-MIB::cpmProcExtInvoked.1.5 = Counter32: 418471
CISCO-PROCESS-MIB::cpmProcExtRuntime.1.5 = Counter32: 90380 microseconds
CISCO-PROCESS-MIB::cpmProcExtUtil5Sec.1.5 = Gauge32: 0
CISCO-PROCESS-MIB::cpmProcExtUtil1Min.1.5 = Gauge32: 0
CISCO-PROCESS-MIB::cpmProcExtUtil5Min.1.5 = Gauge32: 0
CISCO-PROCESS-MIB::cpmProcExtPriority.1.5 = INTEGER: critical(1)
CISCO-PROCESS-MIB::cpmProcExtMemAllocatedRev.1.5 = Gauge32: 23223664 bytes
CISCO-PROCESS-MIB::cpmProcExtMemFreedRev.1.5 = Gauge32: 1784383920 bytes
CISCO-PROCESS-MIB::cpmProcExtInvokedRev.1.5 = Counter32: 418471
CISCO-PROCESS-MIB::cpmProcExtRuntimeRev.1.5 = Counter32: 90380 microseconds
CISCO-PROCESS-MIB::cpmProcExtUtil5SecRev.1.5 = Gauge32: 0 percent
CISCO-PROCESS-MIB::cpmProcExtUtil1MinRev.1.5 = Gauge32: 0 percent
CISCO-PROCESS-MIB::cpmProcExtUtil5MinRev.1.5 = Gauge32: 0 percent
CISCO-PROCESS-MIB::cpmProcExtPriorityRev.1.5 = INTEGER: critical(1)

我编写了一个脚本来 snmpget 所有值以防止计时问题,并按 Allocated - Freed 对它们进行排序:

(删除中间位)

PDU DISPATCHER        3446519088
IP SNMP               1742301596
SNMP ENGINE           792807060
IP Input              635031724
Logger                27247348
TCP Protocols         15053688
Per-Second Jobs       10510488

...

SSM connection manager  0
Crypto IKE Dispatcher  -472
IP Background         -1880
DHCPD Timer           -47424
TTY Background        -103736
LOCAL AAA             -126696
Transport Port Agent  -181900
IP Cache Ager         -1120096
crypto sw pk proc     -2327016
TCP Timer             -606529520
Pool Manager          -1761160256

具有负值的进程似乎没有太多共同点,奇怪的是 PDU DISPATCHER 和 IP SNMP 会使用最多的内存。

我认为这可能归结为共享内存和 IOS 中现代内存管理之前的原始 OID。

所需的数据可能包含在 Cisco 似乎并不经常填充的 OID 中:

1.3.6.1.4.1.9.9.109.1.2.3.1.15 cpmProcessTextSegmentSize
1.3.6.1.4.1.9.9.109.1.2.3.1.16 cpmProcessDataSegmentSize
1.3.6.1.4.1.9.9.109.1.2.3.1.17 cpmProcessStackSize
1.3.6.1.4.1.9.9.109.1.2.3.1.18 cpmProcessDynamicMemorySize

我找不到包含更好数据的任何其他 Cisco MIB,因此我认为没有可靠的方法来获取此信息。