声明：该总结为网友朋友总结，本人是归纳成文，方便各网友学习交流。
在一个高并发系统中 如果突然出现一个应用或者说一个服务突然变得很慢，应该怎么排查？
这个是考线上排查问题能力，没有标准答案，作为开发，假设这种情景出现你怎么诊断问题？
首先：想知道，在实际情况下，怎么知道【一个应用或者说一个服务突然变得很慢】？调用访问的时候会发现的，对于业务流程比较熟悉很重要，先能够初步圈出，可能出现问题的地方，服务监控是必须的，做业务必须要知道自己服务的状态。
1、首先就是想看日志，后来想想看日志确实不太可行，并发量太大的情况下，查日志会很慢，（看日志，pstack strace gdb）。
2、应该从上到下看。----网络，系统，应用。任何一个环节都有可能有问题,首先看网络监控情况，然后看系统（内存，cpu,负载 ）情况。
3、把线程dump出来，用jstack dump 线程调用链，看线程卡到哪里了。然后定位代码，看看赌在哪个函数，是不是调用了重函数。当然先定位到具体应用，再dump。
4、看接口故障率，然后看数据库有没有锁。
5、先看日志，排除了磁盘满了，网络慢，然后看进程，具体到当时几个线程，堵在哪儿。
6、分布式服务一般都是服务治理的，可以看整个调用链的时间图。
7、看监控，监控只是能找到问题 但是不能找到问题原因，什么请求、返回、错误、慢速，这些都是要监控的，告警也要配置好，有问题第一时间知道。
8、假如是网络问题那就找临近的防火墙看对应服务器的并发连接数是否新建连接/半开连接超高，或者有突发流量挤占了资源。同时查对应服务器的磁盘I/O情况和对应那个应用的进程内存占用曲线是否有突发。高并发应用我理解上日志肯定是没法去看的，因为日志量太巨大了。
9、集群或多主机的系统，需要根据监控 看各个主机的CPU 内存 接口IO等，这些能分析一些，如果能得出具体的主机 再分析哪个应用的CPU 内存 异常dump 等。如果涉及到接口机 可以看接口的失败率，应用的话需要排查log了，有时候主机空间不足 内存不足、硬件故障也会导致问题。
10、例子：在银行做安全运维时候，那帮服务器的和网银的一天到晚就说这是网络问题，这绝对网络瘫了。。然后查一圈发现他们一个什么java的问题，说是有个印度小哥把java runtime装了最高版本。但是系统不支持，必须重新装回低版本，就好了。
11、如果是分布式部署多台机器，别的机器没问题，但这台机器有问题。那么更有可能是因为网络或者磁盘导致的，一般这些资源都有zabbox这样的监控。看日志是肯定要的。
12、如果这些机器都是虚拟机的话也有可能是控制器系统的问题。
13、扩展：
阿里，负载均衡和流量清洗系统强大，每年网购高峰期和那几个“节”一过0点的突发流量，很考验负载均衡系统的部署策略。高峰限流是关键，不能冲垮系统，但高峰一限流。。购物车就无法结账了。（异步结帐）
京东，双12 的时候。负载均衡也会出问题。有时候，负载不均衡的情况出现，有针对应用的限流和熔断的，也有针对URL的限流和熔断机制。
另外：DDOS攻击、负载均衡算法没设计好、CDN、DNS等都有可能
本文出自 “努力！奋斗！” 博客，请务必保留此出处http://026mm.blog.51cto.com/8783374/1775760
在一个高并发系统中 如果突然出现一个应用或者说一个服务突然变得很慢，应该怎么排查？
原文地址：http://026mm.blog.51cto.com/8783374/1775760
