【问题标题】:WildFly 17.0.1.Final HeapMemory IssuesWildFly 17.0.1.Final 堆内存问题
【发布时间】:2022-04-10 14:57:35
【问题描述】:

我需要一些关于最近正在生产的 Wildfly 版本的建议或指南。

我们经常看到堆内存峰值,垃圾收集无法正常工作,堆被填满并达到最大 2 GB(这是我们分配的堆),我们需要重新启动应用程序才能恢复正常。当我们分析内存转储时,我们在应用程序代码中找不到任何问题,但我们发现一个类占用了更多内存。该类与 ActiveMQ 和 WildFly 集成有关,该应用程序使用 MDB,我们在 EJB 3.0 上。并且请更多关于我们将 Amazon Corretto 与 WildFly 一起使用。请任何人观察到有关 WildFly 的以下对象的此问题。

当我们分析堆栈跟踪和内存中的对象时,下面的对象拥有更多的内存,它来自 WildFly 类。有人请分享对此的任何想法或想法。

我们正在使用 wildfly-17.0.1.Final 和 Corretto-8.212.04.2(构建 1.8.0_212-b04)。 以下是JVM配置

<jvms>
    <jvm name="default">
        <heap size="2048m" max-size="2048m"/>
        <jvm-options>
            <option value="-server"/>
            <option value="-XX:MetaspaceSize=256m"/>
            <option value="-XX:MaxMetaspaceSize=256m"/>
        </jvm-options>
    </jvm>

堆堆栈跟踪如下

**`**Who reference 1.25gb (71.7%) of byte[]?`**

1,196,563K **(65.3%) 字节[]** Java 静态 org.wildfly.extension.messaging.activemq.broadcast.CommandDispatcherBroadcastEndpointFactory.BROADCAST_MANAGERS {java.util.concurrent.ConcurrentHashMap}.values org.wildfly.extension.messaging.activemq.broadcast.QueueBroadcastManager.broadcasts {java.util.concurrent.LinkedBlockingDeque}**

我们正在使用配置文件“full-ha”在 Wildfly 集群环境中运行 J2EE 应用程序,请查找我们的 ACTIVEMQ 配置

 <subsystem xmlns="urn:jboss:domain:messaging-activemq:7.0">
            <server name="default">
                <cluster password="password"/>
                <statistics enabled="${wildfly.messaging-activemq.statistics-enabled:${wildfly.statistics-enabled:false}}"/>
                <security-setting name="#">
                    <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
                </security-setting>
                <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/>
                <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
                <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
                    <param name="batch-delay" value="50"/>
                </http-connector>
                <in-vm-connector name="in-vm" server-id="0">
                    <param name="buffer-pooling" value="false"/>
                </in-vm-connector>
                <http-acceptor name="http-acceptor" http-listener="default"/>
                <http-acceptor name="http-acceptor-throughput" http-listener="default">
                    <param name="batch-delay" value="50"/>
                    <param name="direct-deliver" value="false"/>
                </http-acceptor>
                <in-vm-acceptor name="in-vm" server-id="0">
                    <param name="buffer-pooling" value="false"/>
                </in-vm-acceptor>
                <broadcast-group name="bg-group1" jgroups-cluster="activemq-cluster" connectors="http-connector"/>
                <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
                <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="bg-group1"/>
                <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
                <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
                <jms-queue name="CSVProcessPendingMessageBean" entries="java:/jms/queue/CSV_PROCESS_PENDING_Q java:jboss/exported/jms/queue/CSV_PROCESS_PENDING_Q"/>
                <jms-queue name="CSVUploadQMessageBean" entries="java:/jms/queue/CSV_UPLOAD_Q java:jboss/exported/jms/queue/CSV_UPLOAD_Q"/>
                <jms-queue name="InboundQMessageBean" entries="java:/jms/queue/CSV_INBOUND_Q java:jboss/exported/jms/queue/CSV_INBOUND_Q"/>
                <jms-queue name="OutboundQMessageBean" entries="java:/jms/queue/CSV_OUTBOUND_Q java:jboss/exported/jms/queue/CSV_OUTBOUND_Q"/>
                <jms-queue name="OutboundMessageBean" entries="java:/jms/queue/VFOREQUEST_Q java:jboss/exported/jms/queue/VFOREQUEST_Q"/>
                <jms-queue name="AutoManualInboundMessageBean" entries="java:/jms/queue/VFOAUTOMANUALRESPOSE_Q java:jboss/exported/jms/queue/VFOAUTOMANUALRESPOSE_Q"/>
                <jms-queue name="InboundMessageBean" entries="java:/jms/queue/VFORESPONSE_Q java:jboss/exported/jms/queue/VFORESPONSE_Q"/>
                <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
                <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
                <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
            </server>
        </subsystem>

【问题讨论】:

  • org.wildfly.extension.messaging.activemq 中的类用于 WildFly 与 ActiveMQ 的集成,但它们是 WildFly 类而不是 ActiveMQ 类。您是否在集群您的 WildFly 实例?请在您的问题中包含您的服务器配置。
  • 感谢您的回复 Justin.. 是的,我们正在集群上运行配置文件 full-ha。我已经在问题中添加了 ActiveMq 配置。如果我遗漏了什么,请告诉我,并对很多遗漏感到抱歉,因为这是我关于堆栈溢出的第一个问题 ..
  • 专家请告诉我任何想法,因为我们在更正集群密码后再次得到了这个。应用程序运行了 2 周,之后这些类的堆内存使用量再次增加

标签: memory wildfly corretto


【解决方案1】:

有同样的问题。这就是问题所在,因为我们迁移到了不支持多播的 Azure:

<broadcast-group name="bg-group1" jgroups-cluster="activemq-cluster" connectors="http-connector"/>
            

【讨论】:

    猜你喜欢
    • 2015-12-03
    • 1970-01-01
    • 1970-01-01
    • 2017-04-02
    • 2018-02-09
    • 2011-11-26
    • 2018-09-26
    • 2012-04-27
    • 1970-01-01
    相关资源
    最近更新 更多