S6520-22SG-SI升级版本 7.1.070-6813P02，老是报内存预警阈值已被超过

一、 内存占用率升高（73% → 83%）问题分析

1. 确认是否为内存泄漏：使用 display memory 和 dis process memory 命令持续观察。如果内存使用率稳定在 83% 左右不再持续增长，则无需干预；如果发现数值还在以每分钟/每小时的速度持续攀升，则可能存在内存泄漏，需收集诊断信息联系厂家。
2. 清理僵尸会话释放内存：部分老版本存在 comsh 进程僵死导致内存不释放的已知缺陷。您可以执行 display process comsh all 查看是否有非当前登录的残留会话。若有，可通过 free user <会话ID> 或 reset process comsh 来安全回收内存。
3. 终极手段：若内存居高不下且影响业务，建议在业务低峰期将设备升级到官方最新推荐的稳定版，或直接重启一次设备以彻底释放碎片化内存。

二、 端口队列2丢包问题分析

1. 毫秒级瞬时突发流量（Micro-burst）：即使您看到的端口平均流量只有几个 G，但在多对一转发模型下，毫秒级的瞬时峰值可能瞬间打满端口，超出固定 Buffer 的缓存能力。
2. 服务器 Bonding 哈希不均：如果您的下联设备（如服务器或录像机）使用了网卡绑定（Bond mode 0 或 mode 4），哈希算法可能导致某一条物理链路流量严重倾斜，引发单端口过载丢包。

1. 开启 Burst Mode（强烈推荐）：这是解决此类突发丢包的首选方案。该模式取消固定区域分配，让所有端口动态共享整个 Buffer，大幅提升容错能力。
   <H3C> system-view [H3C] burst-mode enable
   配置后可通过 display buffer 对比开启前后的 Buffer 分配变化。
2. 精细化调整队列2缓存：如果开启 Burst Mode 后仍有少量丢包，可手动扩大队列2的共享缓存比例：
   H3C> system-view [H3C] buffer egress cell queue 2 shared ratio 100 [H3C] buffer apply
3. 检查下联设备负载均衡：排查下联服务器的 Bonding 模式，若为 mode 0 或 mode 4，尝试更改哈希策略（如改为 layer3+4）或切换为 mode 1 (active-backup) 测试是否还会丢包。

一、内存占用升高并报预警的问题
1. 告警说明
Memory early-warning threshold has been exceeded
你的设备是 S6520-22SG-SI，硬件只有 1GB DRAM，升级后内存从 73% 涨到 83%，已经触发了设备的Early-warning 10% 阈值（Free Ratio 15%，低于 20% 就会告警）。
2. 核心原因
新固件 6813P02 本身功能更全（带 FreeRADIUS、eScan 等扩展包），占用了更多常驻内存；
你的设备只有 1GB 内存，属于低配置型号，跑新版本很容易吃满内存；
日志里可以看到 comsh、xmlcfg、lauthd 等进程占用高，说明 CLI、配置管理、认证服务等进程也在消耗内存。
3. 解决方案（按优先级）
方案 1：回退到原来稳定的 6628P47 版本（最稳妥）
这是最直接的解决方式，版本占用内存低，且你之前运行稳定：
bash
运行
# 1. 上传旧版本文件到flash
tftp x.x.x.x get S6520SGSI-cmw710-system-r6628P47.bin flash:

# 2. 设置为启动文件
boot-loader file flash:S6520SGSI-cmw710-system-r6628P47.bin all

# 3. 重启生效
reboot
方案 2：关闭不必要的功能释放内存（如果不想回退）
bash
运行
# 关闭未使用的扩展功能（如eScan/FreeRADIUS，如不用）
undo feature escan
undo feature freeradius

# 关闭不必要的日志功能
undo info-center enable

# 关闭ARP/ND优化（非必要时）
undo arp fast-forwarding enable

# 保存配置并重启
save
reboot
方案 3：调整内存告警阈值（仅屏蔽告警，不解决实际占用）
bash
运行
system-view
memory early-warning threshold minor 5 severe 3 critical 1
⚠️ 注意：这只是屏蔽告警，不降低内存占用，只是避免刷屏。
二、端口队列 2 丢包 / 拥塞的问题
1. 告警说明
Packet loss occurs in queue 2 of GigabitEthernet1/0/20
output buffer drop packets exceeded the upper threshold
这是典型的端口出方向拥塞导致的队列丢包，和内存升高有直接关联：
内存不足会影响芯片的缓冲区调度，导致队列资源无法及时释放；
高内存占用会让 CPU 处理拥塞通知、流量调度的效率下降，加重丢包；
端口流量突发时，队列 2 的缓冲不够，就会触发丢包告警。
2. 解决方案
1. 先解决内存问题（优先）
内存占用降下来后，芯片缓冲区调度效率会恢复，丢包会明显减少。
2. 调整队列调度参数（缓解拥塞）
bash
运行
system-view
interface GigabitEthernet 1/0/20
qos wrr queue 1 weight 1
qos wrr queue 2 weight 3 # 调高队列2权重，优先调度
qos wfq queue 2 bandwidth 300000 # 给队列2分配更多带宽
3. 排查端口流量是否异常
bash
运行
display interface GigabitEthernet 1/0/20
display qos queue statistics interface GigabitEthernet 1/0/20
看是否有持续的大流量或突发流量，是否需要限流或分流。
三、推荐的处理顺序
优先回退到 6628P47 版本，解决内存占用过高的根本问题；
观察内存占用是否回到 73% 左右，丢包告警是否消失；
如果仍有丢包，再调整队列调度参数；
若必须使用新版本，关闭所有未使用的扩展功能