real时间远大于user时间和sys时间的总和

每个单个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活动

2. 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容量的新服务器上。