上午十点半，门诊高峰时段。
XX省第一人民医院的门诊系统开始”莫名其妙”地变慢——不是全瘫，而是”一点点往下沉”：刚开始挂号响应从2秒变成5秒，人们还能接受；半小时后变成15秒，开始有患者抱怨；一小时后变成30秒以上，缴费窗口前排起了长队，护士们在喊”系统太卡了”。
李主任在看监控：CPU使用了45%，内存还有60%可用，网络流量正常，数据库连接池使用率55%——所有指标都在安全范围内。但系统就是越用越慢，像是一辆在平路上慢慢失去动力的车。
1. 指标正常，但业务异常：最诡异的故障
“重启试试？”有人提议。
“不行，”李主任摇头，”现在是高峰，重启会导致所有正在办理的业务中断，患者会更不满。先查原因。”
这个决定很关键。如果当时选择了重启，问题可能暂时消失，但那个”幽灵”会继续存在，下次以更猛烈的方式爆发。
老林建议从进程层面入手。他们用top命令查看系统进程，发现了一个奇怪的进程：java -jar /opt/his/tmp/cleanup.jar，这个进程的CPU占用率只有0.3%，但VIRT（虚拟内存）高达2GB，RES（物理内存）也有800MB，而且已经运行了超过48小时。
“这个进程是干什么的？”李主任问。
小张回忆起来：这是两周前部署的一个”临时清理脚本”，用于清理临时文件。当时 supposed 是运行一次就退出，但似乎它变成了常驻进程。
他们进一步检查这个进程的打开文件：lsof -p ，发现它打开了一个数据库连接，而且这个连接的状态是”Sleep”，但时间已经超过48小时。
“就是这个’ninja’进程，”老林说，”它占着一个数据库连接不放，而且因为它持续存在，连接池的其他连接被它慢慢挤占。”
但仅仅这一个连接，不至于把连接池全部占满。小吴继续排查，又发现了多个类似的”僵尸进程”：有的已经死亡但父进程没回收（orphaned zombie），有的自己创建了大量线程但从未释放，有的在等待某个永远不来的网络响应（I/O wait）。
2. 清理僵尸：一场高风险的手术
“我们必须清理这些僵尸进程，”李主任说，”但不能影响正在进行的业务。”
他们制定了一个计划：
1. 识别所有空闲超过30分钟的数据库连接
2. 找出这些连接关联的进程
3. 对于确认是僵尸的进程，先尝试优雅终止（SIGTERM），如果10秒内不退出，再强制终止（SIGKILL）
4. 清理后密切观察业务日志，确保没有数据丢失或不一致
第一步，他们用SQL查询了数据库的进程列表：
“`sql
SELECT id, user, host, db, command, time, state
FROM information_schema.processlist
WHERE time > 1800 AND command != ‘Sleep’ OR state = ‘Sleep’ AND time > 1800;
“`
（注：此处为示意逻辑，实际更复杂）
结果发现了80多个超时会话。他们逐一对每个会话对应的应用服务器进程进行标记。
小吴编写了一个自动化脚本：
1. 获取所有空闲超过30分钟的数据库连接ID
2. 通过连接信息反查应用服务器上的进程ID
3. 对进程进行优雅终止，等待10秒
4. 如果进程仍在，强制终止
5. 记录清理日志
脚本运行前，李主任要求：”每清理5个连接，就检查一次业务日志，确保没有异常。”
清理开始。前5个连接顺利清理，无异常。10个、15个、20个… 系统响应时间慢慢改善，从30秒降到了18秒。
但清理到第35个时，系统再次出现短暂闪退——所有页面白屏约15秒。
“停！”李主任喊道。
他们检查发现，这个连接关联的是一个正在执行批量数据同步的任务。虽然这个任务已经”空闲”了35分钟，但它处于一个事务中，一旦强制终止，会导致数据同步中断，部分数据不一致。
“我们不能只看’空闲时间’，”老林说，”还要看当前事务状态。”
他们调整了清理策略：只清理那些”不在活动事务中”的空闲连接。
调整后，清理继续。这次顺利多了。下午一点，清理完成，系统响应时间稳定在4秒以内。但李主任心里明白，这只是临时解决了资源占用问题，那个”幽灵”的制造者——那些不该存在的僵尸进程——是怎么来的，才是根本。
3. 为什么会有僵尸进程？
下午业务低峰期，技术团队开始了根因分析。
第一个发现：应用程序异常处理不当
他们检查了那个cleanup.jar的源码（ decompiled ），发现它在捕获到InterruptedException后，只是简单return，没有真正关闭数据库连接和线程资源。这个jar包是由一个外包团队写的，上线时没有做代码评审。
第二个发现：线程池配置不合理
应用服务器的线程池配置是默认值：核心线程数10，最大线程数200，队列容量1000。在门诊高峰，请求并发达到1500时，线程池会创建大量线程来处理，但这些线程在任务完成后不会立即销毁（核心线程不销毁），导致线程数慢慢积累到200的上限。而这些线程如果因为某种原因阻塞，就会变成”僵尸线程”。
第三个发现：数据库连接泄漏
某些业务代码中，数据库连接获取后，在异常分支里没有正确释放。正常情况下，连接会随着方法结束自动关闭（try-with-resources），但一旦发生异常跳过close语句，连接就”悬空”了。
第四个发现：监控盲区
“我们一直以为连接池使用率55%是安全的，”李主任看着监控图表，”但55%指的是’已分配连接’，不包括’僵尸连接’。如果僵尸连接占用了30%，实际可用连接只有25%，早就该告警了。”
老林补充：”我们的监控只采集了’连接池使用率’这个指标，没有采集’活跃连接率’和’空闲超时连接率’。这就是为什么所有指标正常，但业务已经卡住。”
4. 系统性整改：从被动灭火到主动预防
当晚，李主任主持了故障复盘会。他定了三个整改方向：
第一，建立连接泄漏检测机制
在数据库层面，开启performance_schema，监控长时间未关闭的连接。对于超过30分钟的空闲连接，自动记录堆栈信息并告警。这样，即使发生泄漏，也能在影响业务前发现。
同时，应用层面增加连接池的abandoned回收机制：如果一个连接被借出超过10分钟未归还，强制回收并记录日志。虽然强制回收可能导致该连接的业务失败，但比整个系统拖垮要好。
第二，规范进程生命周期管理
所有后台任务进程必须有明确的启动、停止、监控机制。现在，他们要求：
– 任何后台任务必须打包为systemd service，有明确的ExecStart、ExecStop、Restart策略
– service文件必须包含TimeoutStopSec=30，防止进程拒绝退出
– 所有服务必须提供健康检查接口，供监控系统探测
– 禁止使用”nohup java -jar”这种原始方式启动服务
那个运行了48小时的cleanup.jar，就是因为没有systemd管理，一旦启动就不知道如何停止，只能手动kill。
第三，优化线程池配置和监控
根据业务高峰的并发量（约1500），他们将线程池参数调整为：
– corePoolSize=50（避免线程数过少导致排队）
– maxPoolSize=300（允许弹性扩容）
– queueCapacity=1000（缓冲队列）
– keepAliveTime=60（空闲线程60秒后销毁）
同时，增加线程池监控指标：
– 活跃线程数
– 队列等待数
– 任务完成总数
– 拒绝任务数
这些指标接入现有监控系统，设置阈值告警。
第四，强化代码审查和异常处理规范
所有生产环境部署的代码，必须经过至少一人代码审查，重点审查：
– 资源释放（数据库连接、文件句柄、线程）是否在所有异常路径都能正确关闭
– 是否使用了try-with-resources或类似机制
– 线程池任务是否有超时设置
– 是否有无限循环风险
此外，统一异常处理规范：捕获异常后，必须记录日志（包括堆栈），必须确保资源释放，必须考虑是否需要向上传递。
5. 一个月后：系统稳定运行
整改后的一周内，他们又发现了两起潜在的连接泄漏——都被自动检测机制捕获并及时处理。一个月后，系统没有出现类似的”缓慢失能”故障。
李主任在月度运维会议上说：”这次故障给我们上了一课。它告诉我们，指标正常不代表系统健康。我们需要监控的不仅仅是CPU、内存这些’传统指标’，更要监控’业务健康度’——比如平均响应时间、错误率、吞吐量。”
他还提出了一个概念：”运维的黄金法则是’在用户感知之前发现问题’。当患者开始抱怨’系统卡’时，其实问题已经存在一段时间了。我们的目标是通过精细监控，让系统在用户感知到异常之前，就自动修复或至少自动告警。”
软佳的客户成功经理在回访时，对这次整改给予了高度评价。她说：”我们服务过上百家医院，XX医院这次故障的复盘深度和整改力度，是前三的水平。很多医院故障后只修bug，不建流程，结果同类问题反复发生。”
6. 给运维人员的建议
老林在内部培训中，总结了”僵尸进程防御三原则”：
原则一：资源必须有归属
每个数据库连接、每个线程、每个文件句柄，都必须有明确的创建者、所有者、销毁时机。不能让它”自然死亡”，必须”主动回收”。
原则二：监控要看趋势，看质量
不要只看”总量是否超过阈值”，要看”活跃占比”、”空闲时长分布”、”异常增长趋势”。一个指标从20%升到45%，虽然没到80%的告警线，但趋势已经说明问题。
原则三：应急要有章法，根治要有流程
遇到故障，先按预案处理恢复业务；恢复后必须进行根因分析，找到流程漏洞；然后整改流程，防止同类问题再发生。不能”好了伤疤忘了疼”。
互动话题
你们医院有没有遇到过”监控正常但业务异常”的情况？是怎么发现并解决的？你觉得最应该监控哪些”非传统”指标来预防这类问题？欢迎在评论区分享你的运维实战经验。
> 基于真实医院场景改编，人物均为化名
立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html
手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）
支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
