Ignite не может использовать журнал WAL и освободить буфер ОС при сохранении - PullRequest
0 голосов
/ 06 июля 2018

Ignite не может использовать журнал WAL и освободить буфер ОС при сохранении на

У меня есть один сервер воспламенения с памятью 128 ГБ и постоянным включением для обеспечения безопасности моих данных.

Как я понял из официального документа, мое понимание: Когда Persitent включен, Ignite сначала сохраняет изменения данных в буфере ОС (я проверяю это в качестве буфера / кэша в команде linux free -mh), а затем записывать в журнал WAL, и периодически через контрольно-пропускной пункт для анализа WAL зарегистрируйте и освободите проанализированное дисковое пространство журнала WAL и освободите используемый буфер ОС, исправьте меня, если я ошибаюсь.

Но в моем тестировании, когда Ignite начал обрабатывать трафик, я обнаружил, что буфер ОС быстро увеличивался и проверьте каталог журнала WAL, есть много журналов wal, сгенерированных по порядку, почти такой же, как размер с buff / cache.

[root@Redis1 apache-ignite]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        109G        995M        1.7G        109G
Swap:          127G          0B        127G
      127G

Всего за несколько минут свободный столбец быстро уменьшается по сравнению с увеличением буфера / кэша

[root@Redis1 apache-ignite]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         15G         85G        995M         25G        108G
Swap:          127G          0B        127G

и размер журнала WAL и номера сегментов также продолжают увеличиваться, по-прежнему почти так же, как размер с buff / cache.

У меня есть проверка журнала зажигания, проверка контрольной точки каждые 3 минуты:

[05:30:05,818][INFO][db-checkpoint-thread-#107][GridCacheDatabaseSharedManager] Checkpoint started [checkpointId=9428aebc-f2b0-4d33-bed6-fb9a1ad49848, startPtr=FileWALPointer [idx=341, fileOff=50223036, len=420491], checkpointLockWait=0ms, checkpointLockHoldTime=860ms, walCpRecordFsyncDuration=245ms, pages=89627, reason='timeout']
[05:30:22,429][INFO][db-checkpoint-thread-#107][GridCacheDatabaseSharedManager] Checkpoint finished [cpId=9428aebc-f2b0-4d33-bed6-fb9a1ad49848, pages=89627, markPos=FileWALPointer [idx=341, fileOff=50223036, len=420491], walSegmentsCleared=0, markDuration=1288ms, pagesWrite=844ms, fsync=15767ms, total=17899ms]

Но для вывода команды "free -mh" не удалось освободить столбец "free", увеличиваясь с продолжающимся трафиком, даже когда я остановил трафик, он также не уменьшается, если я продолжаю посылать трафик, доступная память продолжает уменьшаться, и, наконец, объем свободной памяти сокращается примерно до сотни мегабайт,

[root@Redis1 apache-ignite]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         16G        370M        971M        108G        107G
Swap:          127G          0B        127G

Когда это происходит (исчерпание свободной памяти?), Все мои службы, основанные на остановке из-за игнорирования, больше не обрабатывают мой новый запрос, из-за воспламенения он зависает.

Я также замечаю журнал контрольных точек с причиной = «тайм-аут», я не знаю, мог ли этот стенд для этого воспламенения правильно проанализировать журнал WAL и освободить буфер кэша ОС? Есть ли способ, чтобы контрольная точка работала нормально, чтобы освободить память?

У меня вопрос, как я могу сделать что-то, чтобы предотвратить воспламенение исчерпания доступной памяти и сохранить мой сервис доступным с постоянным включением, Я обнаружил, что если я выключаю постоянный, очень быстро запускаю дескриптор и использую кеш менее 1G с тем же трафиком, но когда включен постоянный флаг, Память кеша операционной системы быстро увеличивается, истощая всю доступную память, затем воспламенение не может возобновиться из этого условия и зависает.

Я перепробовал много параметров, используйте WALMODE, LOG_ONLY или BACKGROUND, установите -DIGNITE_WAL_MMAP = false в JVM, установите checkpointPageBufferSize, но ни одного из них можно было бы спасти мой сервис зажигания, он все равно съел бы кэш ОС и исчерпал его.

https://apacheignite.readme.io/docs/write-ahead-log https://apacheignite.readme.io/docs/durable-memory-tuning#section-checkpointing-buffer-size

    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <!-- 10 GB initial size. -->
                    <property name="initialSize" value="#{10L * 1024 * 1024 * 1024}"/>
                    <!-- 50 GB maximum size. -->
                    <property name="maxSize" value="#{50L * 1024 * 1024 * 1024}"/>
                    <property name="persistenceEnabled" value="true"/>

                    <property name="checkpointPageBufferSize" value="#{1024L * 1024 * 1024}"/>
                </bean>
            </property>
          <property name="writeThrottlingEnabled" value="true"/>
          <property name="walMode" value="LOG_ONLY"/>
          <property name="walPath" value="/wal/ebc"/>
          <property name="walArchivePath" value="/wal/ebc"/>
        </bean>
    </property>

Ниже приведена конфигурация моего кэша:

public void createLvOneTxCache() {

    CacheConfiguration<String, OrderInfo> cacheCfg =
            new CacheConfiguration<>("LvOneTxCache");

    cacheCfg.setCacheMode(CacheMode.REPLICATED);
    //cacheCfg.setStoreKeepBinary(true);
    cacheCfg.setAtomicityMode(ATOMIC);
    ebcLvOneTxCache = ignite.getOrCreateCache(cacheCfg);
}

Я пытался изменить параметры, но кэш ОС все еще увеличивается:

    <!-- Enabling Apache Ignite native persistence. -->
    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <!-- 10 GB initial size. -->
                    <property name="initialSize" value="#{4L * 1024 * 1024 * 1024}"/>
                    <!-- 50 GB maximum size. -->
                    <property name="maxSize" value="#{4L * 1024 * 1024 * 1024}"/>
                    <property name="persistenceEnabled" value="true"/>

                    <property name="checkpointPageBufferSize" value="#{4L * 1024 * 1024 * 1024}"/>
                </bean>
            </property>
          <property name="checkpointFrequency" value="6000"/>
          <property name="checkpointThreads" value="32"/>
          <property name="writeThrottlingEnabled" value="true"/>
          <property name="walMode" value="LOG_ONLY"/>
          <property name="walPath" value="/wal/ebc"/>
          <property name="walArchivePath" value="/wal/ebc"/>
        </bean>
    </property>

И быстро запускайте аудит журнала, но кеш также не освобождается.

[07:51:20,165][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint started [checkpointId=fd0c7e68-564a-4b40-9516-bb2a451869e7, startPtr=FileWALPointer [idx=23, fileOff=47849256, len=420491], checkpointLockWait=0ms, checkpointLockHoldTime=77ms, walCpRecordFsyncDuration=233ms, pages=7744, reason='timeout']
[07:51:20,219][INFO][sys-stripe-0-#1][PageMemoryImpl] Throttling is applied to page modifications [percentOfPartTime=0.36, markDirty=16378 pages/sec, checkpointWrite=3322 pages/sec, estIdealMarkDirty=673642 pages/sec, curDirty=0.00, maxDirty=0.40, avgParkTime=21501 ns, pages: (total=7744, evicted=0, written=7744, synced=229, cpBufUsed=0, cpBufTotal=1036430)]
[07:51:22,303][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint finished [cpId=fd0c7e68-564a-4b40-9516-bb2a451869e7, pages=7744, markPos=FileWALPointer [idx=23, fileOff=47849256, len=420491], walSegmentsCleared=0, markDuration=317ms, pagesWrite=24ms, fsync=2114ms, total=2456ms]
[07:51:26,117][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint started [checkpointId=d64991bc-3d2f-4f2c-8175-d7e92f46f0bf, startPtr=FileWALPointer [idx=25, fileOff=35951286, len=420491], checkpointLockWait=0ms, checkpointLockHoldTime=49ms, walCpRecordFsyncDuration=200ms, pages=7605, reason='timeout']
[07:51:28,612][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint finished [cpId=d64991bc-3d2f-4f2c-8175-d7e92f46f0bf, pages=7605, markPos=FileWALPointer [idx=25, fileOff=35951286, len=420491], walSegmentsCleared=0, markDuration=266ms, pagesWrite=23ms, fsync=2472ms, total=2761ms]
[07:51:32,118][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint started [checkpointId=07246861-57ae-4ef5-8419-cb7710d2f72d, startPtr=FileWALPointer [idx=27, fileOff=38042090, len=420491], checkpointLockWait=6ms, checkpointLockHoldTime=60ms, walCpRecordFsyncDuration=185ms, pages=7186, reason='timeout']
[07:51:32,121][INFO][service-#232][PageMemoryImpl] Throttling is applied to page modifications [percentOfPartTime=0.24, markDirty=10738 pages/sec, checkpointWrite=2757 pages/sec, estIdealMarkDirty=310976 pages/sec, curDirty=0.00, maxDirty=0.07, avgParkTime=358945 ns, pages: (total=7186, evicted=0, written=896, synced=0, cpBufUsed=565, cpBufTotal=1036430)]
[07:51:34,534][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint finished [cpId=07246861-57ae-4ef5-8419-cb7710d2f72d, pages=7186, markPos=FileWALPointer [idx=27, fileOff=38042090, len=420491], walSegmentsCleared=0, markDuration=257ms, pagesWrite=29ms, fsync=2387ms, total=2679ms]
[07:51:38,169][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint started [checkpointId=44e6870a-e370-4bd3-8ad9-8252abb0acd3, startPtr=FileWALPointer [idx=29, fileOff=44462293, len=420491], checkpointLockWait=0ms, checkpointLockHoldTime=76ms, walCpRecordFsyncDuration=210ms, pages=7529, reason='timeout']
[07:51:40,668][INFO][db-checkpoint-thread-#108][GridCacheDatabaseSharedManager] Checkpoint finished [cpId=44e6870a-e370-4bd3-8ad9-8252abb0acd3, pages=7529, markPos=FileWALPointer [idx=29, fileOff=44462293, len=420491], walSegmentsCleared=0, markDuration=303ms, pagesWrite=24ms, fsync=2475ms, total=2802ms]


[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        107G        995M        3.5G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        107G        995M        3.5G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        107G        995M        3.5G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        105G        995M        5.6G        109G
Swap:          127G          0B        127G

Когда я останавливаю трафик для обновления кеша и обнаруживаю, что кеш ОС возвращается, но очень-очень медленно, освобождение занимает очень много времени, с быстрой контрольной точкойЧастота 6с. Как это можно быстро обработать?

[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        104G        995M        6.5G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        104G        995M        6.3G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        104G        995M        6.3G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        106G        995M        4.6G        109G
Swap:          127G          0B        127G
[root@Redis1 node00-296a5110-74ad-45e0-bf9c-5c075a4f5fdf]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         14G        106G        995M        4.4G        109G

1 Ответ

0 голосов
/ 06 июля 2018

Совершенно нормально, что ОС кэширует данные на диске, это очень хорошо объяснено здесь linux съел мою оперативную память . Если ваше ядро ​​поддерживает, вы всегда можете установить объем свободной памяти, который может уменьшить паузы, когда Ignite выделяет новые блоки памяти

...