2.9 KiB
【E21】OAP-PE NPB04内存增长导致OOM
| ID | Creation Date | Assignee | Status |
|---|---|---|---|
| OMPUB-1362 | 2024-07-09T21:24:46.000+0800 | 杨威 | 已关闭 |
OAP-PE NPB04于7月3日开始，Proxy Packet I/O模块创建的session数量持续增长，导致Proxy的内存持续上涨，最后触发OOM。luqiuwen commented on 2024-07-15T09:48:21.309+0800:
7月2日至5日18点，从tfe的统计看，控制报文中active-close的数量一直在增加，导致tfe的并发连接数一直在增加，这应该是造成内存上涨的直接原因。
!image-2024-07-15-09-47-03-702.png!
下图是并发连接的统计，可见这一段时间并发连接数一直在增加。 !image-2024-07-15-09-48-21-503.png!
yangwei commented on 2024-07-15T10:00:50.410+0800:
现象
- OAP站点，所有NPB上Proxy的内存均存在上涨的现象（平均使用超过20GB，高于其他站点的5~7GB） ** 以NPB01为例，7月5日前呈持续上涨的趋势，至7月5日后趋于平稳 ** !image-2024-07-15-09-50-19-305.png|width=604,height=424!
- OAP站点，NPB04，7月5日后内存占用仍持续上涨，直至7月9日触发OOM ** !image-2024-07-15-09-51-30-140.png|width=595,height=419!
分析
NPB01的监控显示7.1~7.5之间，Proxy接收到的控制报文中，open状态，多于closing，从而大量session未正常关闭，造成内存占用上涨
!image-2024-07-15-09-43-24-947.png|width=551,height=312!!image-2024-07-15-09-44-21-583.png|width=676,height=306!
sf_classifier监控显示，对应时段（7.2~7.5）内，发送的open和closing控制报文数量基本持平
!image-2024-07-15-09-45-57-616.png|width=838,height=524!
对比sf_classifer和Proxy的计数，open报文计数基本一致，但是sf_classifer的closing报文计数，与proxy收到的closing报文计数，在7月2日7月5日间出现明显的差值（每秒相差约1015），推算与proxy持续维持的session数相符。
!anydesk00002_副本2.png|width=838,height=524!
初步结论：
- OAP站点Proxy内存上涨，原因为在7月2日~7月5日，Proxy接收到的closing报文与open报文不一致相关，进一步的原因为，对应时段sf_classifer发送的closing报文，与Proxy接收到的数量不一致
- OAP NPB04在7月5日后内存持续上涨导致oom的原因待进一步分析
Attachments
60073/anydesk00002_副本2.png
60074/anydesk00002_副本2-1.png
60064/image-2024-07-15-09-43-24-947.png
60065/image-2024-07-15-09-44-21-583.png
60066/image-2024-07-15-09-45-14-762.png
60067/image-2024-07-15-09-45-19-650.png
60068/image-2024-07-15-09-45-57-616.png
60069/image-2024-07-15-09-47-03-702.png
60070/image-2024-07-15-09-48-21-503.png
60071/image-2024-07-15-09-50-19-305.png
60072/image-2024-07-15-09-51-30-140.png