原文在这里: GC日志中real时间比user+sys时间长该如何处理?
GC日志中会详细的记录每一次GC事件所花费的时间信息,每一个GC事件所花费的时间都会以’user’、‘sys’、'real’3个维度来记录,这3个时间是什么意思呢?他们之间有什么区别?
1.real time:GC事件整个过程自然流逝的绝对时间,这个跟钟表上的时间是一致的。(ps:如果GC从8点开始,8点30结束,real time就是30分钟)。
2.user time:cpu花在用户态的时间
3.sys time:cpu花在内核态的时间,也就是说内核发生系统调用所花费的时间,不包括调用lib库的时间,因为这是发生在用户态。
一般的GC事件中,real time是小于sys+user time的,因为一般是多个线程并发的去做GC,所以real time是要小于sys+user time的。比如说:user+sys是2秒,如果是有5个GC线程并发的做垃圾回收,那么real time差不多是2000/5=400ms左右。
但是,有时候会见到real time大于sys+user time的情况,比如:
[Times: user=0.20 sys=0.01, real=18.45 secs]
如果在你的GC日中出现大量的这种日志,说明你的应用可能存在下列问题:IO负载非常重或者是CPU不够用。
1.IO负载繁重
当服务器的IO负载非常重的时候(网络、磁盘访问、用户交互),real time就会变大。应用做GC日志打印的时候,也需要访问磁盘。当磁盘的负载非常重的时候,GC事件就有可能被阻塞,这会导致real time变长。
注意:就算不是你的应用导致的磁盘负载重,如果服务器上其他的应用导致的磁盘负载重也会导致real time变长。
可以用如下命令来监控服务器的磁盘负载情况:
sar -d -p 1
这个命令会输出每秒钟磁盘的读写数量,关于sar的详细使用请参考:http://www.linuxtechi.com/generate-cpu-memory-io-report-sar-command/。
如果你发现服务器的磁盘负载非常重,那么可以考虑下面的方法来解决:
(1)如果是你的应用引起的,优化你的应用的io
(2)杀掉服务器上磁盘负载高的进程
(3)把应用部署到另一台磁盘负载不高的机器上
2.CPU不够用
如果服务器上跑了很多进程,你的应用很不幸没有得到足够的CPU时间,它就需要很多的等待。当你的进程在等待的时候,real time显然就比sys+user时间长了。
可以用top之类的监控工具来监控服务器的cpu使用情况,如果cpu的利用率非常高,你的应用没有得到足够的cpu,那么你可以这样做:
(1)减少服务器上运行的进程,让你的应用可以获得足够的cpu。
(2)增加cpu数量,比如你是使用的云服务,可以更换更多cpu的主机。
(3)把应用部署到有足够cpu的服务器上。
英文原文:https://blog.gceasy.io/2016/12/08/real-time-greater-than-user-and-sys-time/
如果感觉有用,欢迎扫描开头二维码加关注。