如何排查阿里云服务器性能时好时坏的问题？-云小栈

排查阿里云服务器（ECS）性能时好时坏的问题，需要系统性地从资源瓶颈、外部干扰、配置问题、应用层异常和云平台特性五个维度入手。以下是经过实战验证的标准化排查流程与关键检查点：

🔍 一、快速定位：先看「症状」再定方向

现象类型	可能原因优先级
CPU/内存/磁盘I/O周期性飙升（如每5分钟/每小时）	定时任务（crontab）、监控采集、日志轮转、自动备份、应用健康检查
偶发性卡顿（持续几秒~几十秒），无明显资源打满	网络抖动、DNS解析失败、后端依赖（DB/Redis/API）超时、内核锁竞争、NUMA不平衡
高峰时段性能骤降，低峰正常	应用连接池耗尽、数据库连接数/慢SQL、SLB权重不均、带宽打满或突发流量触发限速
重启后暂时正常，数小时后复现	内存泄漏、连接未释放（TIME_WAIT堆积）、文件句柄泄漏、缓存击穿

✅ 第一步：启用阿里云基础监控（免费）
登录云监控控制台 → 查看该ECS实例的 CPU使用率、内存使用率、磁盘I/O等待时间（iowait）、网络入/出带宽、TCP连接数，时间粒度调为 1分钟，观察波动是否与业务日志中的卡顿时间吻合。

🛠 二、深入排查：分层诊断清单（按执行顺序）

✅ 1. 系统层（SSH登录后立即执行）

# ① 检查实时负载与瓶颈进程
top -c          # 关注 %CPU, %MEM, %wa（iowait >20% 表示磁盘瓶颈）
htop            # 更直观（需yum install htop）

# ② 检查I/O等待详情
iostat -x 1 3   # 关注 %util（>80% 表示磁盘饱和）、await（>50ms 异常）、r/s w/s
iotop -o        # 查看哪个进程在大量读写（重点关注 java/python 进程）

# ③ 检查内存与交换
free -h         # 看 available 是否充足，swap 是否被频繁使用（swappiness=1）
cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree"

# ④ 检查网络与连接
ss -s                           # 查看TCP连接总数、TIME_WAIT数量
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n  # 分析连接状态分布
sar -n DEV 1 5                  # 查看网卡收发包错误、丢包（rxerr/s, txerr/s）

# ⑤ 检查内核日志异常
dmesg -T --level=err,warn | tail -20   # 查看OOM killer、硬件错误、驱动警告

✅ 2. 阿里云特有因素（易忽略！）

风险点	检查方式	解决方案
共享型实例（如ecs.s6）CPU积分耗尽	控制台 → 实例详情 → “CPU积分” 标签页；或 `curl http://100.100.100.200/latest/meta-data/instance-types` 确认规格	✅ 升级为通用型（g7）或计算型（c7）；或购买CPU积分包
云盘IOPS/吞吐量超限（尤其SSD云盘）	云监控 → 块存储监控 → 查看 `IOPSUsed` / `IOPSMax`、`ThroughputUsed` / `ThroughputMax`	✅ 升级云盘类型（ESSD PL1→PL2/PL3）；或增加云盘并做LVM条带化
安全组/网络ACL规则导致连接重试	控制台 → 安全组 → 入方向规则；检查是否误配了拒绝规则或端口范围过窄	✅ 使用 `telnet <目标IP> <端口>` 或 `nc -zv <目标IP> <端口>` 测试连通性
SLB后端健康检查失败引发流量震荡	SLB控制台 → 监听 → 健康检查配置；查看后端ECS的健康状态历史	✅ 检查应用是否响应健康检查路径（如 `/healthz`），调整超时时间与阈值

✅ 3. 应用与中间件层

Java应用：

# 检查GC是否频繁（重点关注Full GC）
jstat -gc <pid> 1000 5    # 观察FGC次数和耗时
# 导出堆快照分析内存泄漏
jmap -dump:format=b,file=/tmp/heap.hprof <pid>

MySQL：

SHOW PROCESSLIST;           -- 查看长事务/锁等待
SHOW ENGINE INNODB STATUSG  -- 检查死锁、事务等待
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED;

Redis：
redis-cli info | grep -E "used_memory|connected_clients|blocked_clients|evicted_keys"
若 evicted_keys>0 → 内存不足；blocked_clients>0 → 客户端阻塞（如 BLPOP）

✅ 4. 日志关联分析（关键！）

同步比对以下三类日志的时间戳：
- 系统日志：/var/log/messages, /var/log/secure（SSH登录暴破、服务重启）
- 应用日志：搜索 ERROR, WARN, timeout, Connection refused, OutOfMemory
- 阿里云操作日志：控制台 → 操作审计（ActionTrail） → 筛选该ECS的 StopInstance, ModifyInstanceAttribute 等事件

💡 技巧：用 journalctl --since "2024-05-20 14:00:00" --until "2024-05-20 14:05:00" 快速提取故障窗口日志。

🚨 三、高频陷阱与解决方案（阿里云场景专属）

问题	诊断命令	解决方案
ECS被同宿主机其他租户“吵醒”（Noisy Neighbor）	`cat /proc/sys/kernel/random/entropy_avail`（<100 表示熵池不足）；`perf top` 看是否大量 `__softirqentry_text_start`	✅ 开启 `rng-tools`：`yum install rng-tools && systemctl start rngd`；或升级至独享型实例（如g7ne）
云盘挂载参数不合理（默认noatime缺失）	`mount \| grep "/dev/vdb"` → 检查是否有 `relatime` 或无 `noatime`	✅ 重新挂载：`mount -o remount,noatime /mnt/data`
DNS解析缓慢导致服务启动/调用卡顿	`time nslookup aliyun.com`；`strace -e trace=connect,sendto,recvfrom -p <pid>`	✅ 修改 `/etc/resolv.conf` 使用阿里云DNS：`nameserver 100.100.2.136`（内网）或 `223.5.5.5`（公网）
内核版本过旧存在已知Bug	`uname -r` → 对比阿里云内核更新公告	✅ `yum update kernel` → 重启后选择新内核启动

✅ 四、终极建议：建立长效防护机制

开启阿里云「云监控+ARMS应用监控」：
- ARMS可自动追踪HTTP/DB/Redis调用链，精准定位慢接口（开通入口）
设置告警策略：
- CPU >80%持续5分钟、内存 >90%、iowait >30%、磁盘使用率 >95% → 短信+钉钉通知
定期压测验证：
- 使用 wrk 或阿里云PTS（性能测试服务）模拟峰值流量，验证扩容预案有效性。
架构优化：
- 数据库读写分离、静态资源上OSS+CDN、核心服务容器化（ACK）提升弹性。

📌 总结口诀（便于记忆）

一看监控定范围，二查进程找元凶；
三审云盘与网络，四析日志对时间；
五验依赖防抖动，六升配置避共享；
七建告警早干预，八做压测保上线。

如仍无法定位，可提供以下信息联系阿里云技术支持：
🔹 实例ID + 故障时间段（精确到分钟）
🔹 云监控截图（CPU/内存/IOPS曲线）
🔹 top、iostat -x 1 5、dmesg -T 的原始输出
🔹 应用日志中故障时刻前后的10行（脱敏）

需要我帮你定制某类应用（如Spring Boot/WordPress/MySQL）的专项排查脚本，或生成自动化诊断Shell脚本，可随时告诉我 👇