查centos中间件

生产环境半夜报警，间件磁盘IO飙升到95%，间件top里看不出哪个进程在作怪。间件我ssh上去，间件第一件事就是间件查端口监听——ss -tlnp一敲，8080上挂着个java进程，间件pid 2345。间件可这进程名是间件"java"，鬼知道它跑的间件是Tomcat还是Spring Boot内嵌容器？中间件排查，从来不是间件看进程名这么简单。

先翻/proc/2345/cmdline，间件用tr把空字符换成换行，间件终于看到-Dcatalina.base=/opt/tomcat9。间件好，间件是间件Tomcat。但光知道这个没用——我得确认它到底加载了哪些应用。去/opt/tomcat9/webapps目录下ls，里面躺着三个war包，其中有个叫report-2019.war的，日期戳是三年前的。这种老古董还挂在生产上，八成就是它半夜跑定时任务搞出来的IO风暴。

查中间件不能只盯着应用服务器。MySQL的show processlist甩出来，发现有几十个Sleep连接来自同一个IP——那是另一台Tomcat的连接池没释放。Druid监控页面开着，但密码还是默认的admin/admin，这比不查还危险。我顺手改掉，再去看它的活跃连接数，果然有个连接池配置的maxActive=200，实际并发才30，纯粹浪费内存。

再往底层挖，Redis缓存命中率掉了20%。redis-cli info stats里keyspace_hits和keyspace_misses一算，比值惨不忍睹。查slowlog get 50，全是KEYS *这种O(N)操作——肯定是哪个业务代码在循环里调它。这不算中间件故障，但属于中间件使用不当，得揪出来。

排查Nginx时我习惯先看error.log，而不是access.log。错误日志里一堆upstream timed out，指向后端的Tomcat。配合netstat -anp | grep :8080看TCP连接状态，发现大量TIME_WAIT——这是短连接频繁建立的典型症状。改Nginx的keepalive_timeout 65和upstream里的keepalive 32，问题立刻缓解。

还有个坑容易被忽略：RabbitMQ的管理界面默认只显示vhost里的队列数量，不告诉你哪个队列积压。用rabbitmqctl list_queues name messages consumers一看，有个order_export队列积压了5万条消息，消费者数为0。查代码发现消费者服务因为OOM被Linux杀了，但systemd没配自动重启。这种连带故障，光查中间件本身根本发现不了。

最后说个土办法，但特管用——lsof -i :端口一个个试。虽然粗暴，但能快速定位谁在监听哪个端口。配合strace -p 进程号看系统调用，能直接看到它在读写什么文件、连接哪个socket。有一次就是靠strace发现Tomcat在疯狂打开/tmp/hsperfdata_*文件，最后定位到是JVM的-XX:+UsePerfData参数没关，导致每个线程都创建性能数据文件。

排查中间件这事儿，七分靠经验，三分靠运气。但核心逻辑就一条：从外到内、从端口到配置、从进程到代码，层层剥开。别信什么"一键诊断"工具，生产环境里最靠谱的还是自己动手敲命令。