GC log中real time大于user+sys time,究竟发生了什么？

2023年4月4日 520次阅读

在GC日志中会报告每个GC事件占用的时间。在每个GC事件中，都有“user”、“sys”和“real”时间。这些时间意味着什么?它们之间的区别是什么?
“real”时间是GC事件经过的总时间。这基本上就是你在时钟里看到的时间。
“user”时间是在用户模式代码(内核之外)中花费的CPU时间。
“Sys”时间是在内核中花费的CPU时间。这意味着在内核中执行系统调用所花费的CPU时间，而不是在用户空间中运行的库代码。

在普通的GC事件中，real时间将小于user + sys时间。因为多个GC线程并发工作，所以real时间将少于user + sys时间。假设usr+sys时间是2秒。如果5个GC线程同时工作，那么real应该在400毫秒左右(2秒/ 5个GC线程)。
但在某些情况下，你可能会看到real比usr+ sys时间更大。

2018-08-15T04:27:15.308-0400: 2473.715: [GC2018-08-15T04:27:16.904-0400: 2475.311: [ParNew: 140941K->4245K(157248K), 0.0052220 secs] 264474K->127786K(506816K), 1.6010150 secs] [Times: user=0.07 sys=0.00, real=1.60 secs]

如果你在GC日志中注意到这个场景多次出现，那么它可能表明以下问题之一:

  • 频繁的I / O
  • CPU不足
  1. 频繁IO

当服务器上有大量的I/O活动(即网络/磁盘访问/用户交互)时，real往往会在很大程度上激增。如果服务器上有一个频繁的I/O活动，那么GC事件可能会被搁浅，从而导致real激增。
注意:即使你的应用程序没有频繁的I/O活动，服务器上的其他进程也可能导致频繁的I/O活动，从而导致高real。
您可以在Unix中使用sar(系统活动报告)监视服务器上的I/O活动。
例子:

sar -d -p 1

以上命令每1秒向设备报告读/秒和写/秒。
如果您注意到服务器上的高I/O活动，那么您可以执行以下操作之一来修复问题:
a.如果高I/O活动是由应用程序引起的，那么优化应用程序的I/O活动。
b.消除导致服务器上高I/O活动的进程
c.将应用程序移动到另一个服务器，那里的I/O活动更少

2 CPU不足

如果在服务器上运行多个进程，并且应用程序没有足够的CPU周期来运行，它将开始等待。当应用程序开始等待时, real将大大高于user + sys的时间。
你可以使用“top”命令或监视工具(nagios、newRelic、AppDynamics等)来观察服务器上的CPU利用率。如果注意到CPU利用率非常高，而你的进程没有获得足够的运行周期，那么可以执行以下操作之一来修复问题:
a. 减少服务器上正在运行的进程的数量，这样你的应用程序就有公平的机会运行
b.增加CPU容量——如果你在AWS云(或类似的云)中，移到拥有更多CPU内核的更大的实例上
c.将应用程序移动到有足够CPU容量的新服务器上。

点赞