每个单个GC事件花费的时间都会在GC日志中报告。在每个GC事件中，都有“用户”，“ sys”和“实时”时间。这些时间是什么意思？它们之间有什么区别？
- “ real”时间是GC事件的总经过时间。这基本上是您在时钟中看到的时间。
- “user”时间是用户模式代码（内核之外）花费的 **CPU时间
- “ sys”时间是内核中花费的CPU时间量 。这意味着在内核内部执行系统调用所花费的CPU时间，而不是库代码仍在用户空间中运行。
要了解有关这些时间的更多信息，请阅读(https://blog.gceasy.io/2016/04/06/gc-logging-user-sys-real-which-time-to-use)
在正常的（所有）GC事件中，“ real”时间将小于user+sys时间。这是因为多个GC线程同时工作以分担工作负载，因此实时时间将小于用户+系统时间。假设用户+系统时间为2秒。如果5个GC线程同时工作，那么实时应该在400毫秒左右（2秒/ 5个GC线程）附近。
但是在某些情况下，您可能会看到real时间大于user+sys时间。
例：
[Times: user=0.20 sys=0.01, real=18.45 secs]
如果您在GC日志中发现多次出现此情况，则可能表明存在以下问题之一：
1.繁重的I / O活动
- CPU不足
1.繁重的I / O活动
当服务器上有大量I / O活动（即，网络/磁盘访问/用户交互）时，实时性往往会大幅提高。作为GC日志记录的一部分，您的应用程序进行磁盘访问。如果服务器上有大量I / O活动，则GC事件可能会搁浅，从而导致实时峰值。
注意：即使您的应用程序没有引起繁重的I / O活动，服务器上的其他进程也可能导致繁重的I / O活动，从而导致较高的实时性。这是=来自LinkedIn工程师的精彩文章，解释了由于高I / O活动而遇到的GC问题
您可以在Unix中使用sar（系统活动报告）监视服务器上的I / O活动。
例：
sar -d -p 1
上面的命令每1秒报告一次对设备的读取/秒和写入/秒。有关“ sar”命令的更多详细信息，请参考本教程。(https://www.linuxtechi.com/generate-cpu-memory-io-report-sar-command/)
如果您发现服务器上的I / O活动很高，则可以执行以下任一操作来解决此问题：
a。如果您的应用程序引起了很高的I / O活动，请优化应用程序的I / O活动。
b。消除导致服务器上大量I / O活动的进程。
C。将您的应用程序移到I / O活动较少的其他服务器上。
2. CPU不足
如果您的服务器上正在运行多个进程，并且您的应用程序没有足够的CPU周期运行，它将开始等待。当应用程序开始等待时，实时时间将大大高于用户+系统时间。
您可以使用“ top”之类的命令或监视工具（nagios，newRelic，AppDynamics--）来观察服务器上的CPU使用率。如果您发现CPU利用率很高并且您的进程没有足够的运行周期，则可以执行以下一项操作来解决此问题：
a。减少服务器上正在运行的进程数，以便您的应用程序有运行的机会。
b。增加CPU容量-如果您位于AWS云（或等效版本）中，请移至具有更多CPU核心的更大实例类型。
C。将您的应用程序移到有足够CPU容量的新服务器上。
网友评论