记录遇到的相关问题。
阿里云slb 5xx和4xx波动
现象：
- 告警平台发生 slb 5xx 和 4xx 波动告警
排查过程：
- 通过 slb 日志过滤，5xx 中主要是 502 占比很高，4xx 中主要是 499 的占比很高，只有一个域名出现此状况
- 通过 502 状态码初步判断是后端服务不可用，然后客户端在不断重试，导致 499 状态码的请求增多
- 根据域名和 slb 的监听定位后端服务，检查最底层后端服务，发现 nginx error log 中提示 upstream 无法连接
- upstream 的后端是 php 的服务，查看运行状态正常，服务没有挂掉
- 判断是服务处理不过来，可能是配置的线程数可能太少，影响了服务的处理能力
- 检查配置文件，发现 pm.max_children 配置仅有 5
- 提升 pm.max_children 值到 10 倍到 50，重启 php-fpm
- 观察 nginx error log，发现错误已恢复
后续：
- 仅配置 pm.max_children 并不是一个合理的做法，同时还需要调整 pm.start_servers, pm.min_spare_servers, pm.max_spare_server
pm.start_servers(初始进程值) 一般是 max_children 值的 20%
pm.min_spare_servers(至少保持空闲的进程值) 一般是 pm.start_servers 的 50%
pm.max_spare_servers(最大保持空闲值) 一般是 pm.start_servers 的 2 倍 - 需要注意的是，pm.max_children 需要根据服务器的资源情况来决定
总结：
- 需要根据请求量来评估中间件中关键的参数配置，避免配置过低导致问题
- 架构太过繁琐，接了快 3 层 Nginx，太过重复
Java服务被k8s不断重启问题记录
现象：
- 告警发现服务的 Deployment available 值和配置的不匹配
- 查看服务，发现服务被重启了多次，并且遗留了很多 Error 状态的 Pod
排查过程：
- 查看 Error 状态 Pod 的详细信息
kubectl describe pod xxx
发现 Pod 是因为节点磁盘不够导致被驱逐了 - 进入正在运行的 Pod 中，发现应用目录下很多内存 Dump 文件，观察一段时间，发现数量还在持续增加，进而使磁盘使用率不断升高，导致被驱逐
- 查看服务的 JVM 参数，发现配置了
-XX:+HeapDumpBeforeFullGC
正是此参数导致 Dump 文件不断产生 - 查看监控，发现
FullGC经常发生 - 评估此参数的合理性，去掉重启服务，恢复正常
总结：
- 配置自动 Dump 时需要慎重考虑，因为 GC 过程会导致服务中断
- 对于需要使用内存 Dump 来排查问题，建议在低峰期手动导出，或者使用
-XX:HeapDumpOnOutOfMemoryError参数，仅在发生 OOM 时进行导出，避免频繁自动 Dump ，影响服务正常运行
发表回复