Java Linux高CPU负载上的HornetQ用户

我们正在CentOS 6.3上使用HornetQ 2.2.14。我们在AppServer中遇到了一个CPU使用率高的问题，并已将其缩小到使用探查器的HornetQ用户

具体而言，我们在大约150个消费者的空队列上快速连续调用此方法：

// Called about every 10ms per consumer.
javax.jms.MessageConsumer.receive(10);

这导致大约2个NIO工作线程可以追溯到Netty，在我们其他空闲的Tomcat实例上消耗了大约50%的2个CPU内核

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21939 tomcat    20   0 9061m 1.6g  16m R 55.4 21.2   1:06.88 java
21777 tomcat    20   0 9061m 1.6g  16m S 47.6 21.2   1:29.40 java
21777 tomcat    20   0 9061m 1.6g  16m S  7.3 21.2   1:33.41 java
21763 tomcat    20   0 9061m 1.6g  16m S  6.6 21.2   1:28.84 java
21682 tomcat    20   0 9061m 1.6g  16m S  4.3 21.2   0:26.70 java

问题是，在Windows上使用完全相同的代码和Tomcat配置，CPU核心处于空闲状态。这让我相信这是一个Linux/Netty/HornetQ问题。以前有没有人见过这种情况？如果是，我该如何让它消失

Linux版本：CentOS 6.3 x64 Linux内核版本：Linux版本2.6.32-279.19.1.el6.x86_64

以下是我测试过的两个Java版本，结果相同：

Java(TM) SE Runtime Environment (build 1.7.0_10-b18)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)

---

在我看来，你应该使用MessageListener。。或者只是阻塞更长的时间，比如10秒

。。。重复10毫秒在您的系统上是一个巨大的突发事件。特别是客户端每次都会向服务器发送回调

让消息系统为您完成工作，即在消息到达时让它呼叫您。如果每10毫秒对系统进行一次无意义的轮询，那么就不会有其他结果

正如你自己所指出的，这是你问题的罪魁祸首：

consumer.receive(10);

算算一下，你用这个接收器（10）敲打服务器的每个消费者都让服务器每秒向你发送100条消息，每个消费者说。。。我空了

接收（10）将进行往返，以确保传输中没有消息。因此，您正在用空消息重击服务器

---

基于您强制应用程序的参数，您的应用程序不应该运行良好。对于任何保证接收（10）在返回null之前为空的消息解决方案，您应该使用MessageListener。。或者只是阻塞更长的时间，比如10秒

。。。重复10毫秒在您的系统上是一个巨大的突发事件。特别是客户端每次都会向服务器发送回调

让消息系统为您完成工作，即在消息到达时让它呼叫您。如果每10毫秒对系统进行一次无意义的轮询，那么就不会有其他结果

正如你自己所指出的，这是你问题的罪魁祸首：

consumer.receive(10);

算算一下，你用这个接收器（10）敲打服务器的每个消费者都让服务器每秒向你发送100条消息，每个消费者说。。。我空了

接收（10）将进行往返，以确保传输中没有消息。因此，您正在用空消息重击服务器

---

基于您强制应用程序的参数，您的应用程序不应该运行良好。对于任何保证接收（10）在返回null之前为空的消息解决方案来说。

虽然克莱伯特的回答有点难以接受，但它最终是一个有效的例子。您可以轻松地创建多个消息侦听器，这些侦听器将充当工作器，并允许JMS提供程序调用它们。假设您的目的地是某种队列，则消息侦听器将被公平分布的负载调用，以允许多个线程处理该处理。创建消息侦听器将允许JMS提供程序在消息到达时调用它们，而不是等待客户机使用消息

每次调用receive方法时，它都会按照Clebert所描述的方式运行（他应该知道，他是HornetQ的负责人）

我不确定Netty HornetQ 2.2.14的版本是什么，但我确实在他们的回购协议中发现了一些与之非常相似的问题。也许您可以尝试在应用程序中更新Netty的版本，看看这是否有帮助

---

虽然克莱伯特的答案有点难以接受，但它最终是一个有效的案例。您可以轻松地创建多个消息侦听器，这些侦听器将充当工作器，并允许JMS提供程序调用它们。假设您的目的地是某种队列，则消息侦听器将被公平分布的负载调用，以允许多个线程处理该处理。创建消息侦听器将允许JMS提供程序在消息到达时调用它们，而不是等待客户机使用消息

每次调用receive方法时，它都会按照Clebert所描述的方式运行（他应该知道，他是HornetQ的负责人）

我不确定Netty HornetQ 2.2.14的版本是什么，但我确实在他们的回购协议中发现了一些与之非常相似的问题。也许您可以尝试在应用程序中更新Netty的版本，看看这是否有帮助

---

忘了添加，以下是探查器确定的热点：org.hornetq.core.client.impl.ClientConsumerImpl.receive（）和org.jboss.netty.channel.socket.nio.SelectorUtil.select（）通过切换hornetq使用阻塞IO没有影响。现在不是2个NIO工作线程消耗CPU，而是2个阻塞IO工作线程消耗相同数量的CPU。一个客户端线程和一个服务器线程。如果将超时值增加到30ms，会发生什么。我这样问是因为如果超时值接近实时时钟的分辨率，可能会发生意外情况，我记得时钟正好在10毫秒左右运行。CPU使用率似乎与超时值成正比。如果我降低超时时间，或者使用ClientConsumerImpl.receiveNoWait（），CPU使用率会增加更多。如果我将超时时间增加到30ms，CPU使用率会略有下降，但仍高于预期。也就是说，它的使用率从40%下降到了20%。将HornetQ连接和接收器工厂切换为“在VM中”，而不是仅仅为了测试而使用Netty，问题就消失了。这一定是Linux上Netty的一个问题，因为它在Windows上运行良好