温馨提示×

Ubuntu lsnrctl内存占用高怎么解决

小樊
31
2025-12-05 06:42:58
栏目: 智能运维

Ubuntu 上 lsnrctl 内存占用高的定位与处理

一、先确认是否真的是监听器进程在涨内存

  • 使用系统监控确认对象与趋势:
    • 查看整体内存与缓存:free -h
    • 按内存排序定位进程:top/htop,或使用 ps -eo pid,rss,pmem,pcpu,vsz,args --sort=rss
    • 观察目标进程(通常位于 $ORACLE_HOME/bin 下的 tnslsnr)是否持续增长
  • 使用 Oracle 工具查看监听器状态与会话:
    • 查看状态:lsnrctl status
    • 在线跟踪(短时启用,性能有影响):lsnrctl trace on;关闭:lsnrctl trace off
    • 检查日志:$ORACLE_HOME/network/log/listener.log(异常、重启、连接风暴等线索)
  • 若“used”很高但各进程 RSS 合计不高,可能是内核 slab 占用偏高,需进一步排查 slab。

二、常见根因与对应处理

场景 典型现象 快速验证 处理建议
连接风暴或会话泄漏 短时间内连接数激增,listener.log 出现频繁连接/断开 lsnrctl status 看当前服务/连接数;netstat/ss 看 ESTAB 数量 在应用侧修复连接泄漏、设置合理连接池与超时;必要时在 listener.ora 限制 SID/服务、启用连接速率限制(如 SEC_PROTOCOL_ERROR_TRACE_ACTION)
监听器日志或跟踪过大 磁盘 /var/log 或 $ORACLE_HOME/network/log 快速增大 du -sh $ORACLE_HOME/network/log;ls -lh listener.log 轮转并压缩日志;仅在排障时短时开启 trace,用后关闭
内核 slab 占用高(非进程本身) top 看不出异常进程,但 free 显示 used 高 cat /proc/meminfo 看 Slab;slabtop 观察 dentry 等 先 sync;再 echo 2 > /proc/sys/vm/drop_caches 临时回收;优化业务 IO 与目录遍历;按需调整 vm.min_free_kbytes
统计口径误判(缓存/缓冲) “used”高但可用内存充足,系统无明显卡顿 free -h 中 buffers/cache 占比高 这是 Linux 为提高性能使用的文件缓存,通常无需处理;仅在特殊场景临时 drop_caches(不建议长期)

说明:

  • lsnrctl 是 Oracle Listener 的管理工具,真正常驻的是 tnslsnr 进程;排查与处置应围绕该进程与监听服务进行。
  • slab 高常见于大量短生命周期文件/目录操作导致的 dentry 增长,可结合 atop/slabtop 精确定位。

三、立即可执行的排查与修复步骤

  1. 基线采集
  • free -h、ps -eo pid,rss,pmem,pcpu,vsz,args --sort=rss、top/htop、lsnrctl status、tail -f $ORACLE_HOME/network/log/listener.log
  • 记录:内存总量、used、available、listener 进程 RSS、当前连接数、日志大小与增长速率。
  1. 判断是否为“假高”(缓存/缓冲)
  • 若 buffers/cache 占比高且系统响应正常,优先观察而非清理;如需临时回收:sync && echo 3 > /proc/sys/vm/drop_caches(仅在维护窗口执行)。
  1. 判断是否为“真高”(进程或内核 slab)
  • 若某进程 RSS 持续攀升:结合 lsnrctl status、listener.log、netstat/ss 分析连接来源与频率,联动应用侧优化连接管理。
  • 若各进程 RSS 合计与 free 结果相符但 used 仍高:检查 slab(cat /proc/meminfo;slabtop)。确认为 slab 高后,先 sync,再 echo 2 > /proc/sys/vm/drop_caches 临时释放;随后优化引发 slab 增长的上游行为(如频繁创建/删除文件)。
  1. 控制与优化
  • 限制异常来源:在应用/中间件侧修复连接泄漏、设置超时与池化;必要时在 listener.ora 增加访问控制与日志级别管理。
  • 日志治理:配置 logrotate 对 listener.log 进行按日/按大小轮转与压缩,避免单日志过大。
  • 跟踪排障:仅在问题复现短时开启 lsnrctl trace,用后关闭,避免性能与磁盘压力。

四、监控与长期治理

  • 建立基线阈值与告警:对 listener 进程 RSS、当前连接数、listener.log 增长率设置监控与阈值告警(如通过 Zabbix/Prometheus/脚本)。
  • 例行巡检:每周巡检 free -h、ps/top 输出与日志大小;异常时抓取 lsnrctl status、listener.log 片段与 slabtop 快照留存。

0