Apache ActiveMQ Artemis 分页启动后性能下降

Question

我们有一个 ActiveMQ Artemis 测试部署，我们注意到代理拥有大量消息后性能非常缓慢。这是分页开始的时候。我希望这是正常的。为了在测试后缓解这种情况，我们将代理的 xml 增加了一倍。现在分页（和性能下降）被延迟了。我的问题是除了内存之外还有其他参数可以解决这个问题。

我的broker.xml 是：

<configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
   <core xmlns="urn:activemq:core">

      <ha-policy>
         <replication>
            <master>
               <group-name>master</group-name>
               <check-for-live-server>true</check-for-live-server>
           </master>
         </replication>
      </ha-policy>

      <global-max-size>-1</global-max-size>

      <bindings-directory>/opt/broker/broker-data/bindings</bindings-directory>

      <journal-directory>/opt/broker/broker-data/journal</journal-directory>

      <large-messages-directory>/opt/broker/broker-data/largemessages</large-messages-directory>

      <paging-directory>/opt/broker-data/paging</paging-directory>

      <journal-min-files>25</journal-min-files>
      <journal-type>ASYNCIO</journal-type>
      <journal-max-io>5000</journal-max-io>
      <journal-sync-transactional>false</journal-sync-transactional>
      <journal-sync-non-transactional>false</journal-sync-non-transactional>
      <journal-buffer-timeout>750000</journal-buffer-timeout>
      
      <connectors>
         <connector name="netty-connector">tcp://node1:61616?tcpSendBufferSize=307200;tcpReceiveBufferSize=307200;writeBufferHighWaterMark=1228800;useEpoll=true;useNio=true</connector>
      </connectors>

      <acceptors>
         <acceptor name="netty-acceptor">tcp://node1:61616?tcpSendBufferSize=307200;tcpReceiveBufferSize=307200;writeBufferHighWaterMark=1228800;useEpoll=true;useNio=true</acceptor>
      </acceptors>

      <broadcast-groups>
         <broadcast-group name="my-broadcast-group">
            <group-address>${udp-address:231.7.7.7}</group-address>
            <group-port>9875</group-port>
            <broadcast-period>100</broadcast-period>
            <connector-ref>netty-connector</connector-ref>
         </broadcast-group>
      </broadcast-groups>

      <discovery-groups>
         <discovery-group name="my-discovery-group">
            <group-address>${udp-address:231.7.7.7}</group-address>
            <group-port>9875</group-port>
            <refresh-timeout>10000</refresh-timeout>
         </discovery-group>
      </discovery-groups>

      <cluster-connections>
         <cluster-connection name="my-cluster">
            <connector-ref>netty-connector</connector-ref>
            <connection-ttl>130000</connection-ttl>
            <call-timeout>120000</call-timeout>
            <retry-interval>500</retry-interval>
            <use-duplicate-detection>true</use-duplicate-detection>
            <message-load-balancing>ON_DEMAND</message-load-balancing>
            <max-hops>1</max-hops>
            <discovery-group-ref discovery-group-name="my-discovery-group"/>
         </cluster-connection>
      </cluster-connections>

      <security-settings>
         <security-setting match="#">
            <permission type="createNonDurableQueue" roles="amq"/>
            <permission type="deleteNonDurableQueue" roles="amq"/>
            <permission type="createDurableQueue" roles="amq"/>
            <permission type="deleteDurableQueue" roles="amq"/>
            <permission type="createAddress" roles="amq"/>
            <permission type="deleteAddress" roles="amq"/>
            <permission type="consume" roles="amq"/>
            <permission type="browse" roles="amq"/>
            <permission type="send" roles="amq"/>
            <permission type="manage" roles="amq"/>
         </security-setting>
      </security-settings>

      <address-settings>
         <address-setting match="activemq.management#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <max-size-bytes>-1</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
            <auto-create-jms-queues>true</auto-create-jms-queues>
            <auto-create-jms-topics>true</auto-create-jms-topics>
         </address-setting>
         <address-setting match="#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <!-- with -1 only the global-max-size is in use for limiting -->
            <max-size-bytes>-1</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
            <auto-create-jms-queues>true</auto-create-jms-queues>
            <auto-create-jms-topics>true</auto-create-jms-topics>
            <auto-delete-addresses>false</auto-delete-addresses>
         </address-setting>
      </address-settings>
     
      <!-- address section -->
   </core>
</configuration>

编辑： 最关键的问题是一旦分页启动，即使大部分消息都已消耗，代理也无法恢复到原始性能。

Answer 1

考虑到分页消息需要与持久消息类似地同步到磁盘，并且要设置用于控制刷新频率的参数是page-sync-timeout。如果未设置任何值，则使用默认值（请参阅 the documentation 了解该设置的用途）。

通过查看您的journal-buffer-timeout（并假设设置正确），您的磁盘似乎很慢，因此预计分页消息的性能不会很好，因为磁盘没有足够的 IOPS。 我会首先检查您的磁盘随机写入的预期 IOPS 是多少，并相应地设置page-sync-timeout（1/IOPS，以纳秒为单位），但如果磁盘不够快，请不要指望任何改进。

附加说明：如果您不关心电源故障的持久性，您仍然可以禁用journal-datasync，它应该让任何磁盘写入能够幸存下来，只是为了处理故障（即没有电源故障保证）。如果您使用无共享复制应该没问题，因为备份能够在失败的情况下发挥作用。