虚拟机环境下CP内存限制问题

[lvdeshuii]

CP版本：0.9.3.
1、问题描述：现场虚拟机物理内存约 3.8 GiB，故障取证时系统可用内存仅约 335 MiB。人工执行 systemctl start cloud-probe 后，cpworker 在启动过程中通过 pcap_activate() 创建内核 PACKET_RX_RING 抓包环，并申请接近 2 GB 的内核内存，直接触发系统级 OOM。虚拟机随后失去响应并发生异常复位。

2、本次事件由以下因素共同造成：

直接触发因素：cpworker 创建大尺寸 PACKET_RX_RING 时发生大额内核内存申请。
环境条件：4 GB 业务虚拟机已处于严重内存压力，可用内存仅约 335 MiB。
配置因素：CPM 页面配置的内存限制为 2048 MB，该值实际用于抓包缓冲区计算。
产品健壮性不足：CP v0.9.3 缺少启动前可用内存检查，也未对 CP 实施操作系统级内存硬限制，使超出设备承载能力的抓包内存配置能够演变为系统级 OOM。
风险放大因素：服务配置为 Restart=always、RestartSec=100ms，且未设置 systemd 内存限制，异常退出后存在快速重新拉起的风险。
已确认 CP 创建抓包环是本次系统 OOM 的直接触发因素。OOM 后最终由 OpenStack、watchdog 或其他平台机制执行虚拟机复位，尚需平台侧日志确认，但不影响 CP 侧 OOM 根因判断。

3、建议：

建议当CPM分组策略发生变化时，提前预判CP的内存限制预设值是否大于系统空闲资源，分两种情况：

1. 若cpworker采集进程还未启动，当CP的内存限制预设值是否大于系统空闲资源，不启动cpworker采集进程，并打印日志（必须）
2. 若cpworker采集进程已经启动，当CP的内存限制预设值是否大于系统空闲资源，熔断cpworker采集进程，并打印日志（必须）
3. CPM分组页面增加上述场景的开启/关闭熔断勾选项，以便适应客户对于不同系统的需求（可选，比如核心业务系统的业务等级更高，需要开启；或者其他周边业务系统的业务运行环境资源充足，无需开启）
4. 开启熔断勾选项后，当cpworker被熔断后，在CP列表显示“已熔断”或“未激活”的状态，此时该CP不再参与任何采集策略，必须管理员在CPM手工激活该CP的状态，CP才能重新执行采集策略（可选）

[timmy21]

建议升级到0.94。

1. 0.9.4 默认 memory_policy 为 fixed_nic_buffer，fixed_buffer_size_mb 默认 8 MB/task。即每个 task 的内核 ring 只有 8MB，而不是把整个 2048 MB 内存限制塞进内核。
2. 大块内存转移到用户态共享 pipeline 缓冲区，它是“软上限 + 按需分配”，而非一次性内核占位，这种分配失败是可被捕获的（丢包），对系统更友好；且匿名页可换出、可回收、可被 memory cgroup 约束。