Java web 服务部署在多台服务器上，一台服务 load 飙升如何处理？
一个 Java web 服务部署在多台服务器上，突然其中一台服务器 load 飙升，请问如何定位并处理问题？
【特别说明】此问题属于 BOSS 钓鱼专题，提问者正在招聘高薪岗位。如果你使用真实身份发布回答，BOSS 将可以直接查看你的在线简历，并选择是否与你主动开聊。
回答·105
最热
最新
- 首先我会去定位是由于瞬间请求过多造成的 load 还是程序本身运行出现问题，通过请求数，请求日志，tcp 连接数等对比正常业务量等大致可以判断。 如果是请求过多而其它同类服务都正常，考虑是不是遭受了 dos 攻击，其次是负载均衡策略是不是有问题，导致几台服务器分配到的请求不均匀，再极端点，可能其他几台服务都出了问题，导致全部请求打到了这台机器。 如果是程序本身出现了问题。我回去考虑是不是服务器本身某些资源成为了瓶颈，导致无法及时处理正常业务量的业务，导致程序起了过多线程或者连接，滚雪球一样滚崩了程序。可能主要是通过日志去排查。 经验不多，只能一点点排查。
- 处理思路、方式上基本大致相同 1、首先负载真实服务的硬件、软件配置基本相同，不应该有太大差别，基本都是从物理主机虚出来的主机。 2、负载真实服务的主机，是否还部署着其它服务？ 3、服务的网关（nginx)到真实服务主机是否连通？ 4、各真实服务主机部署项目的配置是否相同？比如 java 项目设置最大最小内存参数等配置。 5、查看 load 飙升主机状态，比如 tcp 数，tcp 状态，服务的一些状态，内存大小，哪些 cpu 进程占用高，一些大事务未完成等等，这些就需要具体问题具体分析。 如果发现飙升的服务很难继续提供服务，就采取应急手段，比如在 nginx 停掉服务，通过一些虚拟化手段增加几台相同的服务负载。 如果是黑客行为，可以通过一些 IP 黑名单，或者一些策略，或者买一些 DDOS 服务来规避风险。
- 1.先停掉问题服务器，看是否会在其他服务节点上出现类似问题。 1.a 如果其他服务器正常，那么需要单独检查问题服务器。 1.a.1 查看负载策略，是否有误。（例如粘滞请求+恶意攻击） 1.a.2 查看问题节点与数据库或者中间件协同工作是否正常。 1.b 如果停掉问题节点后，其他服务节点也出现了问题。 1.b.1 重点查看日志，排除恶意请求的可能。（与问题服务器日志对比，找到相似点） 1.b.2 检查是否缓存击穿，导致雪崩。 1.b.3 检查数据库，是否有死锁。 2.保证其他节点 alive，如果其他节点不可用那么压力自然全都会堆积到某一台服务。 3.检查代码正确性以及保证所有节点代码一致。
- 首先排除负载和网络问题（如果该服务影响生产 先隔离）（服务可用性监控工具） 再确认是 CPU 问题还是内存问题 查看 JVM 内存占用情况（如果是 JVM 内存被占满，CPU 肯定居高不下肯定有内存泄露用 jvisul 查看内存详情和堆栈信息）确认问题所在这种问题拿出内存快照很快能定位 如果内存没问题 单存的 CPU 负载过高 有可能该节点存在额外消耗 找到消耗点（一般是引用的框架 比如日志 dozer 和异步计算类的工具或者其他框架） 查看该机器的日志定位飙升前后的请求 线程（接口，参数，处理逻辑，处理业务）
- 大致跟范先生的差不多 1，先看 tcp 连接数 2，看 nginx 的分配策略 3，最后才看代码是否有逻辑上的问题
- 针对一台服务器 load 飙升，初步想法是死循环导致一直占用 cpu，jvm 虚拟机在不停的 fgc，但是不能减轻系统压力导致系统一直在尝试 fgc，服务不可用 cpu 占用率升高，所以需要查看下服务的 jvm 参数 另外服务部署在多台服务器上需查看下负载均衡的策略等等
- top 查看哪个进程占用 CPU 最高，如果是 JAVA 程序引起的，使用 top -Hp pid 查看是哪个线程，然后将 pid 转换为 16 进制，结合 jstack 与 grep 定位线程执行的代码。另外，也可能是 jvm 配置或者代码编写不当的问题引起的频繁 fgc。
- 1.优先经验判断，a）条件及环境变化引起：磁盘空间，网络通断，数据库上限，最近修改代码有否数据库连接相关，死循环明显问题。b）访问情况分析，用户并发猛曾，是否被攻击，流量分析（80%） 2.以上 30 分钟内不能定位，选忙闲两台机器进入专业分析模式：看 cpu，进程，JAVA 虚拟机，数据库跟踪（15%） 3.以上解决不了，进入代码，数据库分析模式（4%） 4.第二天了，听一部分机器，或者独立一个灰度环境进行埋点跟踪（1%）
- 1.负载异常是一种现象，在处理此类问题的时候，首先从技术体系上有标准的方法论指导自己分析问题，这样才不至于被困住。 2.基于 1，问题也就转成，影响负载的因素有哪些？ 外部因素: 流量方面，流量的瞬间飙升， 集群配置，集群中其他服务异常导致的服务转移， 负载配置，负载均衡策略失效， 调用链路，依赖服务服务不可用(包括依赖的其他服务以及底层数据服务) 外部攻击，服务被攻击等。 本身因素:配置有没有被更改？各种情况下的内存配置。 根据以上的分析，也就有了对应的验证方法。
- 要排查的可能因素很多，定位的手段也很多，关键是看有逻辑思路。 说说我大体上的思路。 一、弄清楚 load 飙升具体是 CPU、内存，还是 IO？通过请求数量和日志等，判断是由于请求数造成的，还是服务自身的运行问题？ 二、如果是这台机器请求比其它正常机器要多得多，考虑负载均衡策略是否失效，服务器是不是受到了网络攻击，是不是这台机器的服务代码版本跟其它不一样，或者是程序代码出现了运行的问题； 三、如果是代码层面的问题，可通过 JVM 和日志排查；
相似问题
推荐关注
正在加载中...