🚨 线上问题排查全手册

# Step 1: 找到占用 CPU 最高的进程
top -c
# 记下 PID，假设 PID = 12345

# Step 2: 找到该进程中占用 CPU 最高的线程
top -Hp 12345
# 记下线程 TID，假设 TID = 12350

# Step 3: 线程ID转十六进制（jstack里用的是十六进制）
printf '%x\n' 12350
# 输出: 303e

# Step 4: 查看线程堆栈，定位到具体代码
jstack 12345 | grep "0x303e" -A 30

# 输出示例：
# "pool-1-thread-5" #28 prio=5 os_prio=0 tid=0x00007f8c40123000 nid=0x303e runnable
# at com.example.service.OrderService.processOrder(OrderService.java:87)
# ↑ 这行就是罪魁祸首！

# 1. 线上务必配好 OOM 自动 dump（JVM 启动参数）
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/heapdump.hprof

# 2. 进程还活着时手动导出 dump
jmap -dump:format=b,file=/tmp/heap_$(date +%s).hprof 12345

# 3. 查看堆内存概览（不需要 dump）
jmap -histo:live 12345 | head -20
# 看哪个类的实例数最多，快速判断泄漏类型

# 4. 用 MAT (Memory Analyzer Tool) 分析 dump
# 打开 .hprof 文件 → Leak Suspects → Dominator Tree

# 生产环境推荐 JVM 参数模板
-Xms4g # 初始堆大小（与最大堆一致，避免动态扩缩）
-Xmx4g # 最大堆大小
-Xmn2g # 年轻代大小
-XX:+UseG1GC # 使用 G1 垃圾收集器
-XX:MaxGCPauseMillis=200 # 目标 GC 停顿时间
-XX:+HeapDumpOnOutOfMemoryError # OOM 时自动 dump
-XX:HeapDumpPath=/data/logs/ # dump 文件路径
-Xloggc:/data/logs/gc.log # GC 日志路径
-XX:+PrintGCDetails # 打印 GC 详情
-XX:+PrintGCDateStamps # GC 日志加时间戳
-XX:MaxMetaspaceSize=256m # 限制 Metaspace 大小

# Step 1: 查看各分区使用率
df -h

# Step 2: 进入使用率最高的分区，逐层找大目录
cd / && du -sh * | sort -rh | head -10

# Step 3: 继续进入大目录，逐层缩小范围
cd /var/log && du -sh * | sort -rh | head -10

# Step 4: 找到具体大文件
find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null

# Step 5: 找已被删除但被进程占用的文件（空间未释放）
lsof | grep "deleted" | sort -k7 -rh | head -10
# 这类文件需要重启占用进程才能真正释放空间

#!/bin/bash
# disk_cleanup.sh - 加入 crontab 每天执行
# crontab -e → 0 3 * * * /opt/scripts/disk_cleanup.sh

# 1. 清理 7 天前的应用日志
find /var/log/app -name "*.log" -mtime +7 -delete

# 2. 清理 3 天前的 gc 日志
find /data/logs -name "gc.log.*" -mtime +3 -delete

# 3. 清理 1 天前的 heap dump（已分析完的）
find /data/logs -name "*.hprof" -mtime +1 -delete

# 4. 清理 Docker 无用资源
docker system prune -f --filter "until=72h"

# 5. 清理 /tmp 下超过 3 天的文件
find /tmp -type f -mtime +3 -delete

# 6. 压缩 Nginx 旧日志
find /var/log/nginx -name "*.log.1" -exec gzip {} \;

# 7. 磁盘使用率告警
USAGE=$(df -h / | awk 'NR==2{print $5}' | tr -d '%')
if [ $USAGE -gt 85 ]; then
  echo "磁盘使用率 ${USAGE}%，超过阈值!" | mail -s "磁盘告警" ops@example.com
fi

# 1. 测试网络连通性
ping 10.0.1.100

# 2. 测试端口是否开放
telnet 10.0.1.100 8080
# 或用 nc（更方便）
nc -zv 10.0.1.100 8080

# 3. 追踪路由，看在哪一跳断了
traceroute 10.0.1.100

# 4. 看本机防火墙规则
iptables -L -n

# 5. 确认服务是否在监听
ss -tlnp | grep 8080

# 1. 查询域名解析
nslookup api.example.com

# 2. 更详细的 DNS 查询
dig api.example.com

# 3. 查看本机 DNS 配置
cat /etc/resolv.conf

# 4. 清除 DNS 缓存
systemd-resolve --flush-caches # Ubuntu
dscacheutil -flushcache # macOS

# 1. 查看各状态连接数统计
ss -s

# 2. 查看 TIME_WAIT 连接数
ss -ant | awk 'NR>1{++S[$1]} END {for(a in S) print a, S[a]}'

# 3. 如果 TIME_WAIT 过多（几万+），调内核参数
# 编辑 /etc/sysctl.conf，添加：
net.ipv4.tcp_tw_reuse = 1 # 允许重用 TIME_WAIT 连接
net.ipv4.tcp_fin_timeout = 30 # 缩短 FIN_WAIT 超时
net.ipv4.tcp_max_tw_buckets = 5000 # TIME_WAIT 上限
net.core.somaxconn = 65535 # 全连接队列大小

# 4. 使配置生效
sysctl -p

# 1. 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; # 超过1秒记录

# 2. 查看最近慢查询
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;

# 3. EXPLAIN 分析执行计划
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'PAID';

# EXPLAIN 关注字段：
# type=ALL → 全表扫描！需要加索引
# type=index → 全索引扫描
# type=ref → 索引查找，较好
# rows很大 → 扫描行数多
# Extra=Using filesort → 额外排序，考虑优化
# Extra=Using temporary → 使用临时表，考虑优化

# 1. 查看最近一次死锁信息
SHOW ENGINE INNODB STATUS;

# 在输出中找 "LATEST DETECTED DEADLOCK" 部分
# 关键信息：
# Transaction 1: 持有锁A，等待锁B
# Transaction 2: 持有锁B，等待锁A
# → 构成了死锁环

# 2. 查看当前锁等待
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
SELECT * FROM information_schema.INNODB_LOCKS;

# 解决方案：
# 1. 统一加锁顺序（所有事务都先锁A再锁B）
# 2. 缩小事务范围，尽快提交
# 3. 添加重试机制（死锁后自动重试）
# 4. 降低隔离级别（RC 比 RR 死锁概率低）

# 1. 查看当前所有连接
SHOW PROCESSLIST;
# 或看完整的（不打断）
SHOW FULL PROCESSLIST;

# 2. 查看最大连接数配置
SHOW VARIABLES LIKE 'max_connections';

# 3. 查看当前连接数
SHOW STATUS LIKE 'Threads_connected';

# 排查思路：
# 1. 连接泄漏？→ 检查代码是否有 close()
# 2. 慢查询占连接？→ SHOW PROCESSLIST 看哪些查询卡着
# 3. 连接池太小？→ 调大应用侧 maxPoolSize

# 临时处理：杀掉空闲连接
KILL <thread_id>;

# 在从库执行
SHOW SLAVE STATUS\G

# 关注字段：
# Seconds_Behind_Master → 延迟秒数（0 表示同步）
# Slave_IO_Running → Yes 才正常
# Slave_SQL_Running → Yes 才正常
# Last_Error → 最近错误

# 常见延迟原因：
# 1. 主库大事务 → 从库需要同样时间回放
# 2. 从库配置低 → CPU/IO 跟不上
# 3. 网络延迟 → 主从之间带宽不够
# 4. 从库在跑报表 → 资源争抢

# 应急处理：
# 1. 读流量切回主库（临时）
# 2. 停掉从库上的报表/分析查询
# 3. 并行复制（slave_parallel_workers）

# 1. 查看慢日志
SLOWLOG GET 10

# 2. 查看慢日志配置
CONFIG GET slowlog-log-slower-than

# 常见慢的原因：
# 1. BigKey → 单个 value 几 MB 甚至几十 MB
# 排查：redis-cli --bigkeys
# 解决：拆分大 key、压缩 value、改用 hash 分段存储

# 2. 复杂命令 → SORT、SINTER、LRANGE 0 -1
# 解决：避免全量操作，用 SCAN 替代 KEYS

# 3. 内存不足触发频繁淘汰
# 排查：INFO memory 看 used_memory 和 maxmemory

# 1. 查看内存使用情况
INFO memory

# 关注字段：
# used_memory → 已使用内存
# maxmemory → 最大内存限制
# used_memory_percent → 使用率
# mem_fragmentation_ratio → 碎片率（>1.5 需清理）

# 2. 查看淘汰策略
CONFIG GET maxmemory-policy

# 建议配置：
# 缓存场景 → allkeys-lru（淘汰最久未使用的）
# 有过期时间 → volatile-lru（淘汰有过期时间且最久未使用的）

# 3. 扫描过期 key
redis-cli --scan --pattern "session:*" | wc -l

# 4. 查看某个 key 的内存占用
MEMORY USAGE user:session:10086

# Kafka 查看消费 Lag
kafka-consumer-groups --bootstrap-server localhost:9092 \
  --describe --group my-consumer-group

# 输出关注：
# LAG 列 → 积压的消息数
# CURRENT-OFFSET → 当前消费到哪了
# LOG-END-OFFSET → 最新消息到哪了

# RabbitMQ 查看队列积压
rabbitmqctl list_queues name messages consumers

# RocketMQ 查看消费进度
./mqadmin consumerProgress -g my-consumer-group

# 1. 死信队列配置（以 RabbitMQ 为例）
# 消费失败 N 次后自动进入死信队列
# 人工处理死信，不影响正常消费

# 2. 监控告警配置
# Lag > 1000 → P3 告警（关注）
# Lag > 10000 → P2 告警（处理）
# Lag > 100000 → P1 告警（紧急）
# 消费者下线 → P1 告警（立即处理）

# 3. 消费幂等性
# 消费逻辑必须幂等，防止重复消费导致数据错乱
# 方案：唯一ID + Redis 去重 / 数据库唯一索引

# 4. 消费限流
# 防止积压恢复时瞬间打爆下游
# 配置：prefetchCount = 10~50（不要太大）