admin/geedge-jira
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6a8bfef5778fc7ddd06fa05776bf1ecd0f61d4c4
geedge-jira/md/OMPUB-670.md
hello 46daec8ae4 first
2025-09-14 21:52:36 +00:00

8.6 KiB
Raw Blame History

【E21现场】BOLE-IGW 多块NPB CPU均接近100%

ID Creation Date Assignee Status
OMPUB-670 2022-10-15T17:53:41.000+0800 杨威 已关闭

 

2022-10-15 BOLE-IGW 站点流量割接完毕，流量接入系统后，10.225.11.1/10.225.11.2/10.225.11.5  出现CPU告警，几乎所有CPU核持续在98%~100%之间。

排查处理结果：

从BOLE-IGW NPB上fs2_sysinfo.log日志显示

Tcp_Link_NEW:48975

Udp_link_NEW: 13630

单NPB流量：8Gbps

 

正常情况TCP+UDP新建连接数1Gbps=2000左右属于正常

目前新建连接数TCP+UDP=62605 过高 。

打开10.225.11/2/5 DDOS_Bypass 功能

将etc/sapp.toml中的stream_bypass_enabled 由0改完1 重启sapp。

重启之后CPU 降为最多80%左右，告警消除。

 

附件包含：

SSM-IGW  fs2_sysinfo.log

打开DDOS_bypass前 BOLE-IGW-05 fs2_sysinfo.log 及CPU情况,打开后fs2_sysinfo.log详情 及CPU情况

从DOS Events及session records查看到的相关数据信息截图。

 

 liuyang commented on 2022-10-18T09:39:26.149+0800:

根据2022.10.17现场反馈信息补充如下（如果遗漏或者信息不清楚，请备注以便现场同事补充）：

BOLE-IGW的5个NPB开着ddos bypass开关，当晚上流量高峰时（单NPB流量6.5Gbps左右）依然CPU告警，新建连接数还是很高（TCP+UDP新建6.5W/s左右）。

原因：Nezha CPU告警是40/43=93%左右告警；触发DDOS Bypass是单核超95%且持续500毫秒，所以当流量峰值且新建连接高时，即使开了DDOS Bypass，CPU也会超过告警阈值。

!image-2022-10-18-09-39-16-594.png|width=621,height=305!

!image-2022-10-18-09-38-22-432.png|width=608,height=354!

!image-2022-10-18-09-38-37-072.png|width=600,height=275!

yangwei commented on 2022-10-18T10:22:20.545+0800:

[~liuju] 麻烦补充下功能端以下信息，辅助判断

  • 单核perf信息，命令 perf top -C [core_id]
  • 功能端 sysinfo信息，命令 cat [sapp_run_path]/sysinfo.log
  • 功能端 规则扫描信息， 命令 cat [sapp_run_path]/tsg_static_maat.status，cat [sapp_run_path]/app_sketch_maat.status

liuju commented on 2022-10-18T20:39:45.033+0800:

[~yangwei] 在观察到10.225.11.5 再次出现CPU告警时，采集了现场你需要的数据内容以及该NPB过去1天的资产监控数据详情，已上传到附件中。

liuju commented on 2022-10-19T16:44:06.635+0800:

2022-10-19 BOLE-IGW 10.225.11.5  sapp添加了5个核。

 

目前/opt/tsg/sapp/etc/sapp.toml配置如下：

worker_threads=48

bind_mask=[5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52]

 

/opt/tsg/tfe/conf/tfe/tfe.conf配置如下：

nr_worker_threads=1

zhengchao commented on 2022-10-19T17:07:43.685+0800:

将Top SNI Learning的Limit改为100条试试。

yangwei commented on 2022-10-19T19:06:56.177+0800:

阶段性原因分析如下：

  • 现象 ** 10.15号流量恢复后，Bole-IGW站点NPB报CPU使用告警
  • CPU使用量变化

** 观察10.15之后的CPU使用情况，在开启DDoS Bypass后，使用率较开启前平滑，没有出现之前大部分CPU使用至100%的情况，但是高峰期使用率仍然高于NZ告警阈值 ** !image-2022-10-19-18-40-03-374.png|width=557,height=294! ** 查看历史记录，该站点在10.15恢复前，CPU使用率较为规律，峰值使用量接近告警阈值，但是整体在阈值以下 ** 在10.15恢复流量后（期间有对TSG进行升级和修复操作），整体CPU使用量有所上升 ** !image-2022-10-19-18-36-44-180.png|width=346,height=386!

  • CPU使用分布 ** 使用perf top观察CPU使用高的核，发现占比高的集中在自动机扫描函数，以及部分由于升级jemalloc带来的free malloc函数（升级前使用dictator作为内存池，没有这部分消耗） ** !image-2022-10-19-18-43-06-186.png|width=552,height=208! ** 观察扫描状态统计输出，发现TSG_OBJ_FQDN的扫描命中率高于94% ** !image-2022-10-19-18-44-25-300.png|width=819,height=307! ** 配合sapp的流统计，该站点主要会话为C2S的单向流，与该台NPB整体流量不高（6.5Gbps）,但是新建连接数较高的现象相符（通常C2S侧的负载长度小于S2C侧） ** !image-2022-10-19-18-46-53-312.png|width=618,height=338!
  • 原因推测 ** 原因1 使用jemalloc带来CPU使用增加 *** sapp升级后，改用jemalloc作为内存池，增加了CPU使用，参见https://docs.geedge.net/pages/viewpage.action?pageId=82871119的记录，整体增加5% *** 十一之前，Bole IGW中部分NPB已经升级该版本的sapp，并未触发CPU使用告警，不是决定性原因 ** 原因2 推测修复TopSNI学习bug后，整体的SNI扫描命中率提升，造成CPU使用率提升 *** bug参见https://jira.geedge.net/browse/OMPUB-664
  • 操作 ** 修改Top SNI Learning的Limit为100条，用于验证原因2推测

liuju commented on 2022-10-19T21:32:27.287+0800:

已将Top SNI Learning的Limit改为100条

liuju commented on 2022-10-19T22:46:12.737+0800:

2022-10-19 上午BOLE-IGW 10.225.11.5  sapp添加了的5个核，下午现在已重新绑回去了恢复之前配置，重启了sapp tfe

yangwei commented on 2022-10-24T09:56:57.133+0800:

记录

  • 问题1：TopSNI学习到*.com ** 周四将TopSNI数量调整为100后，FQDN的命中率仍然在85%以上 ** 导出学习到的100条SNI后发现，存在*.com的条目 *** 原因为会话日志中存在www.com的SNI日志 *** 按TopSNI学习的规则，需要访问量大于一定基数后，才能进入学习条件，可知www.com的访问量已达到一定规模 *** 直接访问https://www.com，能够正常返回含www.com的SNI，排除流量异常的可能性 ** 参考：自动学习或需要加入纠错规则
  • 问题2：周四将ToSNI改成1条后，FQDN命中率降至46%，但是仍然存在高峰期CPU使用告警 ** 后续 *** 排除jemalloc带来的CPU消耗，提供一个不带jemalloc的sapp找一片NPB进行验证 *** 结合历史流量记录，分析是否流量变化导致的CPU性能不够

yangwei commented on 2022-10-25T16:47:54.281+0800:

10.24更新Bole一台不带jemalloc的sapp，CPU使用无明显变化，仍然告警

yangwei commented on 2022-10-25T16:54:20.545+0800:

根据从NZ导出的每个IGW站点第五台NPB升级前后的监控统计（9.24和10.22，同为周六），观察中午12:00的Throughput、Connection，对比结果如下：

!image-2022-10-25-16-54-48-494.png|width=608,height=58!

  • MWV和DIR站点流量无明显变化
  • Bole、SSM和BJR近一个月流量显著上升 ** 最大带宽增幅出现在SSM，达到48%，从4.7Gbps上涨至7Gbps ** 会话增长幅度最大的为BJR的37.1%，流量基础从3.96Gbps上涨至5.33Gbps
  • Bole的流量增幅仅次于BJR，而且该站点会话数显著高于其他站点，平均每Gbps会话量达到2400，较第二的MWV站点高出2.27倍

liuju commented on 2023-02-21T14:53:06.592+0800:

BOLE-IGW 流量在从90Gbps降低至目前50Gbps后，CPU告警消除。 故暂时关闭该issue。

Attachments

31788/app_sketch_maat.status

31791/BOL-IGW-T9K001-NPB05.html

31789/fs2_sysinfo+(5).log

31707/image-2022-10-18-09-38-22-432.png

31708/image-2022-10-18-09-38-37-072.png

31709/image-2022-10-18-09-39-16-594.png

31870/image-2022-10-19-18-36-44-180.png

31871/image-2022-10-19-18-38-48-643.png

31872/image-2022-10-19-18-40-03-374.png

31874/image-2022-10-19-18-43-06-186.png

31875/image-2022-10-19-18-44-25-300.png

31876/image-2022-10-19-18-46-53-312.png

32130/image-2022-10-25-16-54-48-494.png

31790/tsg_static_maat.status

31657/微信图片_20221015124139.png

31656/微信图片_20221015124226.png

31655/微信图片_20221015124401.png

31654/微信图片_20221015124410.png

31653/微信图片_20221015124431.png

31652/微信图片_20221015124456.png

31651/微信图片_20221015124544.png

31650/微信图片_20221015124615.png

31649/微信图片_20221015124648.jpg

31648/微信图片_20221015124700.png

31647/微信图片_20221015124753.png

31658/微信图片_20221015131442.png

31659/微信图片_20221015131503.png

31787/微信图片_20221018153649.png

31786/微信图片_20221018153656.png

31785/微信图片_20221018153702.png

31784/微信图片_20221018153707.png