Подробности среды:
Centos 6.8 HornetQ 2.3.25SP10 Jboss 6.4
java-версия java-версии "1.7.0_151" среда выполнения OpenJDK (rhel-2.6.11.0.el6_9-x86_64 u151-b00)
uname -a:
2.6.32-696.16.1.el6.x86_64 # 1 SMP Ср 15 ноября 16:51:15 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux
У нас есть 4 узла Jboss с конфигурацией, как показано ниже
64 ГБ ОЗУ 8 ядер ЦП
Мы используем 4 сервера Jboss в кластерном режиме.Наш продукт представляет собой платформу управления сетью, в которой мы будем управлять и настраивать устройства.Об изменении состояния устройств будет сообщено через сообщения JMS (HornetQ).
Описание проблемы:
Одна из наших клиентских сред состоит из 19 тыс. Устройств.
Когда мы пытаемся опубликовать уведомление о статусе в теме, его получение получает подписчик вотсроченная манераКогда мы говорим «отложено», оно варьируется от 3 до 4 часов до 1-2 дней.Это влияет на среду наших клиентов, и в настоящее время они находятся в критическом состоянии, чтобы решить эту проблему.
Пожалуйста, сообщите нам, если есть какие-либо известные проблемы с этой версией hornetQ и как мы можем преодолеть эти проблемы.Существуют ли какие-либо параметры настройки, которые мы можем настроить на сервере, чтобы повысить производительность HornetQ.
Параметры HornetQ указаны ниже
<hornetq-server>
<clustered>true</clustered>
<persistence-enabled>true</persistence-enabled>
<cluster-password>newClusterPassword</cluster-password>
<jmx-management-enabled>true</jmx-management-enabled>
<transaction-timeout>60000000</transaction-timeout>
<journal-type>ASYNCIO</journal-type>
<journal-min-files>2</journal-min-files>
<connectors>
<netty-connector name="netty" socket-binding="messaging"/>
<netty-connector name="netty-throughput" socket-binding="messaging-throughput">
<param key="batch-delay" value="50"/>
</netty-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
<netty-acceptor name="netty" socket-binding="messaging"/>
<netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver" value="false"/>
</netty-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>
<broadcast-groups>
<broadcast-group name="bg-group1">
<socket-binding>messaging-group</socket-binding>
<broadcast-period>5000</broadcast-period>
<connector-ref>
netty
</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="dg-group1">
<socket-binding>messaging-group</socket-binding>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<diverts>
<divert name="CMPDatabase-changes-divert">
<address>jms.topic.clustered.CMPDatabaseChange</address>
<forwarding-address>jms.topic.database-changes</forwarding-address>
</divert>
<divert name="CEMSDatabase-changes-divert">
<address>jms.topic.clustered.CEMSDatabaseChange</address>
<forwarding-address>jms.topic.database-changes</forwarding-address>
</divert>
<divert name="ProvisioningDatabase-changes-divert">
<address>jms.topic.clustered.ProvisioningDatabaseChange</address>
<forwarding-address>jms.topic.database-changes</forwarding-address>
</divert>
<divert name="ConnectionStatus-changes-divert">
<address>jms.topic.connectionStatusTopic</address>
<forwarding-address>jms.topic.clustered.connectionStatusTopicCluster</forwarding-address>
</divert>
</diverts>
<cluster-connections>
<cluster-connection name="my-cluster-topics">
<address>jms.topic.clustered</address>
<connector-ref>netty</connector-ref>
<reconnect-attempts>5</reconnect-attempts>
<discovery-group-ref discovery-group-name="dg-group1"/>
</cluster-connection>
<cluster-connection name="my-cluster-queues">
<address>jms.queue.clustered</address>
<connector-ref>netty</connector-ref>
<reconnect-attempts>5</reconnect-attempts>
<discovery-group-ref discovery-group-name="dg-group1"/>
</cluster-connection>
<cluster-connection name="my-cluster-database-changes">
<address>jms.topic.database-changes</address>
<connector-ref>netty</connector-ref>
<reconnect-attempts>5</reconnect-attempts>
<discovery-group-ref discovery-group-name="dg-group1"/>
</cluster-connection>
</cluster-connections>
<security-settings>
<security-setting match="#">
<permission type="send" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
</security-setting>
</security-settings>
<address-settings>
<address-setting match="#">
<dead-letter-address>jms.queue.DLQ</dead-letter-address>
<redelivery-delay>5000</redelivery-delay>
<max-delivery-attempts>3</max-delivery-attempts>
<max-size-bytes>104857600</max-size-bytes>
<page-size-bytes>10485760</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<redistribution-delay>1000</redistribution-delay>
</address-setting>
</address-settings>
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/ConnectionFactory"/>
</entries>
<connection-ttl>-1</connection-ttl>
<reconnect-attempts>-1</reconnect-attempts>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
<ha>true</ha>
<block-on-acknowledge>true</block-on-acknowledge>
<retry-interval>1000</retry-interval>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<reconnect-attempts>-1</reconnect-attempts>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
</entries>
<connection-ttl>-1</connection-ttl>
<reconnect-attempts>-1</reconnect-attempts>
</pooled-connection-factory>
</jms-connection-factories>
<jms-destinations>
<jms-queue name="DLQ">
<entry name="/queue/DLQ"/>
</jms-queue>
</jms-destinations>
</hornetq-server>
Собран проблемный HornetQСтатус темы с сервера, как показано ниже.Вывод jms-topic = connectionStatusTopic - JBOSS Node1
[домен @ jmp-кластер: 9999 /] / хост = 005056a547be / сервер = сервер1 / подсистема = обмен сообщениями / hornetq-сервер = по умолчанию / jms-topic = connectionStatusTopic: read-resource (include-runtime = true, include-defaults = true) {"result" => "success", "result" => {"delivery-count" => 289, "durable-message-count "=> 0," durable-subscription-count "=> 0," records "=> [" topic / connectionStatusTopic "]," message-count "=> 289L," messages-Added "=> 184020L," non-durable-message-count "=> 289," non-durable-subscription-count "=> 6," subscription-count "=> 6," virtual "=> false," topic-address "=>" jms.topic.connectionStatusTopic "}}
Вывод jms-topic = connectionStatusTopic - JBOSS Node2
[domain @ jmp-Cluster: 9999 /] / host = 005056a5078a / server = server1 / subsystem = Messaging/ hornetq-server = по умолчанию / jms-topic = connectionStatusTopic: ресурс чтения (include-runtime = true, include-defaults = true) {"исход" => "успех", "результат" => {"delivering-count "=> 29," durable-message-count "=> 0," durable-subscription-count "=> 0," records "=> [" topic / connectionStatusTopic "]," message-count "=>29L, "messages-add" => 58548L, "non-durable-message-count" => 29, "non-durable-subscription-count" => 6, "subscription-count" => 6, "временный" => false, "topic-address" => "jms.topic.connectionStatusTopic"}}
Вывод jms-topic = connectionStatusTopic - JBOSS Node3
[domain @ jmp-Cluster: 9999 /] / host = 005056a56838 / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic: read-resource (include-runtime = true, include-defaults = true) {"result" => "success"," result "=> {" delivery-count "=> 3060," durable-message-count "=> 0," durable-subscription-count "=> 0," records "=> [" topic / connectionStatusTopic "], "message-count" => 3060L, "messages-добавлено" => 285018L, "non-durable-message-count" => 3060, "non-durable-subscription-count" => 6, "subscription-count"=> 6," временный "=> ложь,"topic-address" => "jms.topic.connectionStatusTopic"}}
Вывод jms-topic = connectionStatusTopic - JBOSS Node4
[domain @ jmp-Cluster: 9999 /] / host = 005056a5f871 / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic: read-resource (include-runtime = true, include-defaults = true) {"result" => "success", "result" => {"delivery-count" => 144, "durable-message-count "=> 0," durable-subscription-count "=> 0," records "=> [" topic / connectionStatusTopic "]," message-count "=> 144L," messages-Added "=> 69738L," non-durable-message-count "=> 144," non-durable-subscription-count "=> 6," subscription-count "=> 6, "orary" => false, "topic-address" => "jms.topic.connectionStatusTopic "}}
Несколько раз печатались предупреждения, которые также были прикреплены.
[hornetq-core-client-2.3.21.2.Final-redhat-1.jar: 2.3.21.2.Final-2019-02-27 08: 43: 34,387 WARN [org.hornetq.core.server] (Thread-9 (HornetQ-server-HornetQServerImpl :: serverUUID = e32b2ce0-4643-11e7-b8e5-43b6d7a70187-412588133)) HQ222192: Размер обнаружения дублированного кэша () слишком велик, 20000.Оно должно быть не больше количества сообщений, которые могут быть помещены в буфер конформации () 1 048 576.2019-02-27 08: 43: 34,393 WARN [org.hornetq.core.server] (Thread-21 (HornetQ-server-HornetQServerImpl :: serverUUID = e32b2ce0-4643-11e7-b8e5-43b6d7a70187-412588133)) HQ222192:размер обнаружения дублированного кэша () слишком велик 20000.Оно не должно превышать количество сообщений, которые могут быть помещены в буфер конформации () 1 048 576.