Зажечь кучу, не отпустить, это утечка памяти?

Question

У меня есть 20-минутное испытание под давлением, во время которого размер кучи свободной JVM падает с 97% до 3%. Даже если я подожду 5 часов, количество свободного места не изменится. Если я снова попытаюсь пройти тест, у G C будет слишком много работы, что приведет к длительной паузе JVM. Я использую 2.7 Ignite, я не сохраняю данные в куче tje, я сохраняю данные с помощью jdbcthin.
Я думал, что когда мой тест закончится, куча JVM осознает, но это не похоже на это.

Я прикрепил свойства JVM и приведенную ниже конфигурацию.

Свойство JVM

JVM_OPTS="$JVM_OPTS -Xms10g -Xmx10g -server"
JVM_OPTS="$JVM_OPTS -XX:+AlwaysPreTouch"
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSClassUnloadingEnabled"
JVM_OPTS="$JVM_OPTS -XX:+CMSPermGenSweepingEnabled"
JVM_OPTS="$JVM_OPTS -XX:+ScavengeBeforeFullGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark"
JVM_OPTS="$JVM_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/alidata/soft/ignite/heapdump -XX:+ExitOnOutOfMemoryError"
JVM_OPTS="$JVM_OPTS -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy"
JVM_OPTS="$JVM_OPTS -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -Xloggc:/alidata/soft/ignite/gc/gc.log"

Свойства конфигурации

<bean id="grid.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">

    <!-- Configure internal thread pool. -->
    <property name="publicThreadPoolSize" value="96"/>

    <!-- Configure system thread pool. -->
    <property name="systemThreadPoolSize" value="16"/>

    <!-- Configure query thread pool. -->
    <property name="queryThreadPoolSize" value="96"/>

    <property name="systemWorkerBlockedTimeout" value="#{60 * 60 * 1000}"/>

    <property name="failureHandler">
        <bean class="org.apache.ignite.failure.StopNodeFailureHandler"/>
    </property>
        <!-- Enabling Apache Ignite native persistence. -->
  <property name="dataStorageConfiguration">
    <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
      <!-- Enable write throttling.-->
      <property name="writeThrottlingEnabled" value="true"/>
      <!-- Set concurrency level -->
      <property name="concurrencyLevel" value="4"/>

      <property name="defaultDataRegionConfiguration">
        <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
          <property name="persistenceEnabled" value="true"/>
          <!-- Increasing the buffer size to 1 GB. -->
          <property name="checkpointPageBufferSize"
                    value="#{1 * 1024L * 1024 * 1024}"/>
          <!-- Setting the size of the default region to 4GB. -->
           <!-- 1 GB initial size. -->
          <property name="initialSize" value="#{1L * 1024 * 1024 * 1024}"/>
          <property name="maxSize" value="#{8L * 1024 * 1024 * 1024}"/>

          <!-- Enabling RANDOM_2_LRU eviction for this region.  -->
            <property name="pageEvictionMode" value="RANDOM_2_LRU"/>
        </bean>
      </property>
      <!-- Size of the WAL (Write Ahead Log) segment -->
      <property name="walSegmentSize" value="#{1 * 1024 * 1024 * 1024}"/>

      <property name="walCompactionEnabled" value="true" />

      <property name="walCompactionLevel" value="1" />

      <!-- Set the page size to 4 KB -->
      <property name="pageSize" value="#{4 * 1024}"/>
      <!--
          Sets a path to the root directory where data and indexes are
          to be persisted. It's assumed the directory is on a separated SSD.
      -->
      <property name="storagePath" value="/alidata/soft/ignite/persistence"/>

      <!--
          Sets a path to the directory where WAL is stored.
          It's assumed the directory is on a separated HDD.
      -->
      <property name="walPath" value="/alidata/soft/ignite/wal"/>

      <!--
          Sets a path to the directory where WAL archive is stored.
          The directory is on the same HDD as the WAL.
      -->
      <property name="walArchivePath" value="/alidata/soft/ignite/wal/"/>
    </bean>
  </property>
  <property name="discoverySpi">
    <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
      <property name="failureDetectionTimeout" value="60000"/>
      <property name="ipFinder">
        <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
          <property name="addresses">
            <list>
              <value>172.16.14.14:47500..47509</value>
              <value>172.16.14.15:47500..47509</value>
              <value>172.16.14.16:47500..47509</value>
              <value>172.16.14.17:47500..47509</value>
            </list>
          </property>
        </bean>
      </property>
    </bean>
  </property>
   </bean>

3% изображения

Можете ли вы дать мне какие-либо предложения по устранению этой проблемы?

Answer 1

Apache Ignite не использует слишком много кучи, если только вы не используете кэширование в куче.

Пожалуйста, убедитесь, что вы не сохраняете слишком много данных в куче во время теста.

Я рекомендую собрать дамп кучи, проанализировав его, например, с помощью Eclipse MAT, чтобы увидеть, что там происходит.

Answer 2

Если у вас недостаточно времени, чтобы предоставить небольшого репродуктора, опишите ваш сценарий давления. Это действительно важно для расследования. Основная причина огромного количества соединений в ConnectionManager.usedConn не закрыта JDB C соединения и курсоры запросов (QueryCursor) в нативном API.

AI 2.7 использует соединения ThreadLocal и имеет меньше потенциальных утечек для простых случаев. Нам пришлось изменить логи диспетчера соединений c для выполнения «ленивого» режима (чтобы уменьшить использование кучи для огромных наборов результатов).

Answer 3

Я вижу, что куча удерживается ConnectionManager.usedConns.

Однако не существует выпущенных Apache версий Ignite, которые имеют класс ConnectionManager. Это, конечно, не в 2.7.

Если вы используете какие-то ваши собственные сборки из основной ветки, вы вроде как сами по себе. Рассмотрите возможность обновления до последних сборок из ветки ignite-2.8, эта проблема может быть там исправлена. Релиз еще не выпущен, но код доступен и предположительно более стабилен, чем то, что вы используете.

В любом случае. Вы на самом деле не используете Apache Ignite и уж точно не AI 2.7.