Ubuntu 上 lsnrctl 内存占用过高的定位与优化
一、先厘清对象与总体思路
- lsnrctl 是 Oracle Net Listener 的命令行管理工具，实际长期占用内存的是后台的 监听器进程（LISTENER）；偶尔执行 status/stop/start 的 lsnrctl 子进程本身通常占用不大。优化前先确认你看到的是 LISTENER 还是 lsnrctl 子进程，避免误判。总体思路是：先定位（确认对象与趋势）→ 查因（日志、连接、配置）→ 优化（参数、网络、系统）→ 验证（压测与回看趋势）。
二、快速定位占用来源
- 确认对象与趋势
- 查看进程：top/htop 中按 M 排序，或用 ps 精确查看 RSS（常驻内存）：
- top -p $(pgrep lsnrctl)
- ps -eo pid,rss,pmem,pcpu,vsz,args --sort=rss | head
- 观察一段时间内的 RSS 是否持续增长，判断是否存在泄漏或连接堆积。
- 检查监听器状态与日志
- 状态与连接：lsnrctl status（关注 Services、Current Log File、Total Handles）
- 实时日志：tail -f $ORACLE_HOME/network/log/listener.log（关注频繁连接/断开、TNS 错误、解析异常等）
- 检查系统层面内存结构
- 区分缓存与真实占用：free -h、vmstat 1 5
- 若整体“已用”高但 available 充足，多为可回收的 page cache/buffers，不必紧张。
- 若怀疑内核对象：cat /proc/meminfo | awk ‘{sum=$2/1024} {print $1, sum " MB"}’；再用 slabtop 观察 Slab 是否异常增长（如 dentry、inode 等）。
三、面向监听器的优化动作
- 连接与超时治理
- 控制并发与生命周期：在 listener.ora 中为监听或 SID 段设置合理的连接上限与超时（如 MAX_CONNECTIONS、INBOUND_CONNECT_TIMEOUT、重试相关参数），避免海量半开/短连接耗尽资源；参数名与可用性随版本/平台有所差异，修改前以你的 Oracle 版本文档为准。
- 日志与诊断开销
- 将 LOG_LEVEL_LISTENER 调整为合适级别（仅在排障时临时开启 DEBUG/ADMIN），避免高频日志导致 I/O 与内存压力；定期归档与清理 $ORACLE_HOME/network/log 下的历史日志，确保磁盘与文件系统健康。
- 网络与解析优化
- 核对监听地址与端口无冲突，服务名解析正确；必要时优化网络参数（如启用 TCP Fast Open、合理的 backlog、NIC 队列与驱动），降低连接风暴对监听器的冲击。
- 变更与重启
- 调整 listener.ora 后执行：lsnrctl stop → lsnrctl start 使配置生效；变更前做好备份与窗口期评估。
四、系统层面的配合调优
- 先监控、后调优：用 free、vmstat、smem、pmap、slabtop 建立“占用—回收—增长”的基线，再决定改动方向与幅度。
- 谨慎清理可回收缓存（仅在必要时、低峰期执行）：
- sync && echo 3 | sudo tee /proc/sys/vm/drop_caches（会释放 page cache/dentries/inodes，可能导致短时 I/O 抖动）
- 若判断为 Slab 异常增长，先定位具体类型（如 dentry），再优化业务/文件系统访问模式，而不是一味清缓存。
- 内核参数（示例，需结合负载与容量评估）：
- 降低换页倾向：sysctl -w vm.swappiness=10（减少匿名页被过早换出）
- 控制脏页回写：sysctl -w vm.dirty_ratio=20；sysctl -w vm.dirty_background_ratio=10（避免突发写放大）
- 回收压力：sysctl -w vm.vfs_cache_pressure=50（视 dentry/inode 压力微调）
- 连接治理与系统资源
- 在数据库与应用侧启用/优化连接池，复用连接，减少短连接风暴直达监听器。
- 保障充足的 文件句柄/内核网络参数（如 somaxconn、file-max），避免资源枯竭导致异常排队与重试。
五、验证与回退
- 回归验证
- 复测 lsnrctl status、连接建立/断开速率、listener.log 增长速率与错误数；对比优化前后的 RSS/RES 曲线与系统 available 内存。
- 使用 vmstat 1 5、iostat -dx 1 5 观察是否仍有频繁换入换出与 I/O 抖动。
- 回退与兜底
- 任何参数调整都应可回退；若优化无效或出现新异常，优先恢复最近一次稳定配置，再分段排查。
- 如出现内核/Slab 异常且影响稳定性，优先修复业务或文件系统访问模式，再考虑重启监听器或系统（作为兜底手段）。
