S4-8G 常见问题排查速查

发布时间:2026-06-10 12:14

8G 内存机型的异常大体逃不出三类：内存高、IO 慢、连接数满。一句话结论：先分类再动手，比重启碰运气有效得多，重启能掩盖现象，掩盖不了原因。下面按问题逐条给出原因和排查动作。 内存占用高，先查什么？ 第一步跑 ps aux --sort=-rss | head -5，找出吃内存前五的进程。常见原因依次是：数据库缓冲池配大了（检查 innodb_buffer_pool_size 是否超过 4G）、Java 堆没封顶（进程启动参数里找不到 -Xmx 就要警惕）、缓存服务无上限（Redis 没设 maxmemory）。预防动作：每个吃内存的服务都显式写上限，总和控制在 6.5G 以内，给系统留余量，新服务上架前先过一遍这条规矩。查到元凶后不要急着杀进程，先确认它是主服务还是附属进程，杀错会让故障升级。 IO 等待高是什么原因？ top 里 us 低而 wa 高，就是 IO 等待。常见原因：数据库在跑全表扫描或备份任务、日志量暴增（du -sh /var/log/* 逐层排查）、内存不足引发的换页（vmstat 1 看 si、so 列）。处理顺序：先确认是不是换页，是则回到内存问题；不是，再用 iotop 定位是哪个进程在大量读写。预防：备份和批处理安排在低峰期，日志配好轮转切割，logrotate 的配置值得每周扫一眼。云盘的 IO 性能有上限，超出规格的读写压力只能靠升配或拆分解决，软件优化救不了硬件瓶颈。 连接数满了怎么处理？ 现象是报错 connection refused 或 too many connections。先 ss -s 看 TCP 总量与状态分布；TIME_WAIT 巨多通常是应用没复用连接，检查数据库连接池的 maxPoolSize 等参数；MySQL 报 too many connections 则是业务连接超出 max_connections，临时调大参数能救急，根治要靠连接池收口。预防：压测时记下正常连接数水位，超出水位即告警。发过 too many connections 的机器，事后核对告警有没有配上，这类故障最不该靠用户投诉来发现。 收尾：三类问题的共同起点是"先看整体，再看进程"。登录机器后先跑 free、iostat、ss 三条命令，半分钟内就能缩小包围圈，多数时候答案就藏在这三条命令的输出里。排查过程顺手记进内部文档，同类问题第二次出现时直接翻记录。