日志警告:检测到线程饥饿或时钟跳跃(管家delta = springHikariConnectionPool)

时间:2016-08-01 16:35:59

标签: hikaricp

我使用HikariCP 2.4.6并在Tomcat 8启动时收到警告信息:

01-Aug-2016 11:18:01.599 INFO [RMI TCP Connection(4)-127.0.0.1] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'Spring MVC Dispatcher Servlet'
[2016-08-01 11:18:01,654] Artifact blueberry:war exploded: Artifact is deployed successfully
[2016-08-01 11:18:01,655] Artifact blueberry:war exploded: Deploy took 33,985 milliseconds
Aug 01 2016 11:26:52.802 AM [DEV] (HikariPool.java:614)
WARN : com.zaxxer.hikari.pool.HikariPool - 9m13s102ms - Thread starvation or clock leap detected (housekeeper delta=springHikariConnectionPool).

我没有看到任何其他错误或问题从数据库读/写。这是值得关注的吗?我试着四处寻找,但没有运气。

我们还使用Hibernate 4.3.8.Final over MySQL 5和MySQL 5.1.39连接器与Spring 4.1.0.RELEASE。我们正在努力升级到Hibernate 5,看看是否会消失,但不知道这是否重要。

6 个答案:

答案 0 :(得分:14)

我刚才注意到HikariCP(2.4.7)的稍新版本可以解决此问题出现在我的实例上。

为什么时钟跳跃检测可能合法地发生,这是一个很好的rundown。引用Brett Woolridge的外部链接:

  

这在管家线程上运行,每30秒执行一次。如果你使用的是Mac OS X,那么clockSource就是   System.currentTimeMillis(),clockSource的任何其他平台   System.nanoTime()。理论上两者都是单调递增的,但是   各种事情都会影响到NTP服务器等。大多数操作系统都是   旨在处理后向NTP时间调整以保留   时间流动的幻觉。

     

这段代码说,如果时间倒退(现在< previous),或者如果   时间已经过去了#34;超过两个管家期间(更多   超过60秒),然后可能发生一些奇怪的事情。

     

可能会发生一些事情:

     
      
  1. 您可能正在虚拟容器(VMWare,AWS等)中运行,因为某些原因导致维护工作特别糟糕   时间流逝的错觉。

  2.   
  3. 因为在管家线程中发生了其他事情 - 特别是关闭空闲连接 - 对某些人来说可能是这样   关闭连接的原因是阻止管家线程更多   超过两个看家期(60秒)。

  4.   
  5. 服务器很忙,所有CPU挂起,正在发生线程饥饿,这阻止了管家线程的运行   两个以上的家政期间。

  6.         

    考虑到这些,也许你可以提供额外的背景。

         

    编辑:请注意,这是基于HikariCP 2.4.1代码。确保你   正在运行最新的版本。

(看起来参数已在最新代码中的警告声明中更新。)

答案 1 :(得分:12)

如果您在本地运行该应用程序而计算机进入睡眠状态,则会发生另一个季节。在这种情况下,您无需进行任何明智的配置。

答案 2 :(得分:1)

当我在Linux机器上运行带有微服务的spring boot应用程序时,我遇到了同样的问题。经过调查发现,该服务器只有8GB内存。将内存(RAM)增加到16GB解决了我的问题。

答案 3 :(得分:1)

我遇到这个问题是因为实体的 hashCode 方法中存在无限循环。

两个实体有 OneToMany 关系,我使用 lombok @Data 注释,它通过为每个属性调用 equals 方法来生成 hashcodehashCode() 实现本身导致无限循环。

答案 4 :(得分:1)

发生这种情况的另一个原因是垃圾收集过多,当垃圾收集在两次内务线程执行中运行了更长的时间,试图释放一些内存(例如,恰好在应用程序线程运行“选择”查询时)。由于 GC 阻塞了包括内务线程在内的所有应用程序线程,因此我怀疑时钟因此而“跳跃”。

答案 5 :(得分:0)

我在AWS T2 micro 1GB RAM实例中的MySQL春季启动工作中遇到了这个问题。经过一个小时的努力,没有任何进展,观察到CPU使用率正在接近100%。然后,我使实例T2介质具有4 GB RAM和2个vCPU。在那之后我没问题