线上成绩排查相比于coding，是一个低频的任务，很多人不会常常遇到。一旦需求停止成绩排查的时分，往往是重要且紧急的，因此成绩排查的效率，就显得尤为重要。有些线上成绩，比较直观，比如磁盘运用率高、网络流量高这种，借助适宜的工具很快能定位到缘由;但关于一些复杂的成绩，如系统Load高、RSS占用高、内存溢出等，需求结合多方面的数据才能定位到缘由。这时分，需求有正确的解题思绪，并辅以适宜的工具，才能高效地处置成绩。
目前业界排查成绩的优秀工具还是挺多的，比如国际阿里开源的Arthas、PerfMa开源的为终结功用成绩而生的xPocket，Java官方的JMC(JDK Mission Control)、Eclipse的MAT(Memory Analyzer Tooling)，以及我不断很推崇的神器Async-Profiler。上述只是罗列了一些比较盛行的开源工具，商业工具如jProfiler、YourKit等也都树立了波动的用户群体，这些工具功用各有差异。当然这不是本文描画的重点，就不详细展开了。
在对这些工具停止横向比照时我们发现，他们的目的都是为了处置一些特定的成绩，假设我们有明晰的成绩排查思绪，结合这些工具，可以很快处置成绩。
而关于一些复杂场景，尤其是一些生疏的复杂成绩，在没有眉目的状况下，纵然有各种神兵利器，也无计可施。线上成绩排查犹如开车，老司机轻车熟路，新手则手忙脚乱。当然假设新手有老司机加以指点，也能够很快地处置成绩。
但成绩是，这种老司机并不常见，也不能够时辰都能帮你。我们可以去网上查阅其别人总结的成绩排查套路，再结合我们本人的场景，去尝试处置成绩，我也是常常这么干的。但这种方式效率依然不高，缘由有三个：
信息检索的成本：我们需求花时间去翻阅材料，去跟本人的场景婚配以判别能否适宜本人;
试错的成本：有些材料不适宜我们的场景，我们按照材料去尝试，有能够被带沟里去，糜费时间;
成绩排查需求借助于一些第三方工具，而这些工具在消费环境需求安装、配置和运用，也需求花较多的时间成本。
针对线上成绩排查的特点和现状，我们能否可以构建一个系统，这个系统会针对各种线上成绩的排查构成一个知识(套路)库，针对每一种成绩，都有对应的套路和自动化工具协助我们去定位成绩。本文将结合一个比较有代表性的线上成绩的排查进程，来讨论这种方式的可行性。
二、成绩排查的套路化本章将以RSS占用高为例来对成绩排查的套路化停止阐明。RSS占用高是很多人遇到过的成绩，这个成绩触及的要素比较多，比较有代表性。当然在开启了Swap的运转环境中，Swap高也是RSS高的一种表象，异曲同工。
RSS是Resident Set Size(常驻内存大小)的缩写，用于表示进程运用了多少内存(RAM中的物理内存)。假设我们遇到进程RSS接近效劳器的物理内存，那就意味着你需求关注运用的安康水平了，这意味着运用前面很有能够出现OOM的成绩，比如进程被OOM killer杀死，或许容重视启，或许因运用Swap而速度变慢。
针对RSS高的成绩，首先我们需求知道的是，Java进程消耗的内存绝不只仅是你设置的Xmx或堆内存的用量这么复杂，Java进程占用的内存主要分为2大部分：on-heap(堆内内存)和off-heap(堆外内存)。而堆外内存又包含JVM本身消耗的内存、JVM外的内存。所以，后续的排查思绪我们也是按照堆内内存、JVM内存、JVM外内存3个方向来顺序展开。
1. 堆内存能否太大首先要确认一下Java运用的堆内存能否太大，由于JVM本身也会消耗一些内存，所以你至少需求预留出部分外存存给JVM运用。假设运用触及较多的网络通讯，那还需求预留一些内存给堆外运用，所以普通来说你的堆内存最多为效劳器物理内存的75%(阅历值，需依据运用本身特点调整)，如4G内存效劳器，那么堆内存最大为3G。
堆内存用量的查看手腕十分多，置信各个公司的基础架构团队都提供了可视化的监控手腕，当然也可以经过原生命令jcmd GC.heap_info查看，如图1所示：
假设Java进程的堆内存用量已接近或超过物理内存的75%，那么基本可以确定堆内存用量过大。这时可以调小Xmx来控制堆内存用量。假设Xmx不能减小，可以经过dump堆内存+MAT或JFR(Java Flight Recorder)+ JMC(JDK Mission Control)来剖析内存占用/分配状况，经进顺序调优来增加堆内存用量。
假设到此RSS占用呈波动趋向，我们就可以告一段落了，否则要继续前面的步骤。
2. 能否存在少量ARENA区假设堆内存不大，那么继续排查非堆内存。首先去看一下ARENA区，在高并发的运用中，往往ARENA区占用的内存会比较多。为什么先看ARENA区的内存占用呢?是由于这个步骤是不需求重启JVM进程就可以完成的。
接上去我们直接进入排查成绩环节。执行如下命令：
sudo -u pmap -x |sort -gr -k2 |less
假设存在少量大小为65536或60000左右的内存区域，则很大能够是ARENA区域占用了太多的内存，如图2所示：
这种状况下，最复杂粗犷的办法是在JVM启动参数中添加配置：
export MALLOC_ARENA_MAX=1
需求留意的是，上述的数值只能是1，其他大于1的数值经实际证明是无法控制ARENA数量的。
3. 非堆内存能否开支过大假设前面2个步骤事先都没有发现成绩，还有很多内存你不知道消耗在哪里了，那么我们末尾第3步：开启Native Memory Tracking。前面说过，Java运用的执行，JVM本身也需求消耗一些内存的，经过开启Native Memory Tracking，我们就能知道JVM本身消耗了多少内存。
书归正传，经过修正JVM参数并重启Java进程开启NativeMemory Tracking：
-XX:NativeMemoryTracking=detail
进程重启后，可以经过NMT的一些子命令(summary/detail/baseline/diff)查看Native Memory的占用状况：
sudo -u jcmd VM.native_memory detail
图3是在运用baseline树立了基线的状况下用detail.diff看到的各内存区的变化状况：
(责任编辑：admin)