orientdb 2.1.11 процесс java, потребляющий слишком много памяти

Мы запускаем OrientDB 2.1.11 (Community Edition) вместе с JDK 1.8.0.74.

Мы замечаем, что потребление памяти’ orientdb ‘ java медленно ползет вверх, и через несколько дней база данных становится нечувствительной (мы должны остановить/запустить Orientdb, чтобы освободить память).
Мы также заметили такое поведение через несколько часов при индексации базы данных.
Общий размер базы данных составляет всего 60 ГБ и не более 200 миллионов записей!

Как вы можете видеть ниже, он уже потребляет VIRT(11.44 ГБ) RES (8.62 ГБ).

Мы запускаем CentOS 7.1.икс.

Даже измените кучу от 512 до 256M и модифицированный diskcache.bufferSize до 8GB
MAXHEAP= — Xmx256m

ORIENTDB максимальный ДИСККАШ в МБ, например, ENTER-Dstorage.diskCache.bufferSize=8192 для 8GB

MAXDISKCACHE= » — Dstorage.diskCache.bufferSize=8192″

верхний выход:

Tasks: 155 total,   1 running, 154 sleeping,   0 stopped,   0 zombie 
%Cpu(s):  0.2 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 16269052 total,   229492 free,  9510740 used,  6528820 buff/cache
KiB Swap:  8257532 total,  8155244 free,   102288 used.  6463744 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2367 nmx      20   0 11.774g 8.620g  14648 S   0.3 55.6  81:26.82 java

выход ps aux:

nmx       2367  4.3 55.5 12345680 9038260 ?    Sl   May02  81:28 /bin/java 
-server -Xmx256m -Djna.nosys=true -XX:+HeapDumpOnOutOfMemoryError 
-Djava.awt.headless=true -Dfile.encoding=UTF8 -Drhino.opt.level=9 
-Dprofiler.enabled=true -Dstorage.diskCache.bufferSize=8192 

Как контролировать использование памяти?
Есть ли утечка памяти CB?

2 ответа

  1. Не могли бы вы установить следующую настройку для JVM-XX:+UseLargePages-XX:LargePageSizeInBytes=2m .
    Это должно совле ваш вопрос.

  2. эта страница решила мою проблему.
    в двух словах:
    добавьте эту конфигурацию в базу данных:

    static {
        OGlobalConfiguration.NON_TX_RECORD_UPDATE_SYNCH.setValue(true); //Executes a synch against the file-system at every record operation. This slows down records updates but guarantee reliability on unreliable drives
        OGlobalConfiguration.STORAGE_LOCK_TIMEOUT.setValue(300000);
        OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD.setValue(-1);
        OGlobalConfiguration.FILE_LOCK.setValue(false);
        OGlobalConfiguration.SBTREEBONSAI_LINKBAG_CACHE_SIZE.setValue(5000);
        OGlobalConfiguration.INDEX_IGNORE_NULL_VALUES_DEFAULT.setValue(true);
        OGlobalConfiguration.MEMORY_CHUNK_SIZE.setValue(32);
        long maxMemory = Runtime.getRuntime().maxMemory();
        long maxMemoryGB = (maxMemory / 1024L / 1024L / 1024L);
        maxMemoryGB = maxMemoryGB < 1 ? 1 : maxMemoryGB;
        long cacheSizeMb = 2 * 65536 * maxMemoryGB / 1024;
        long maxDirectMemoryMb =  VM.maxDirectMemory() / 1024L / 1024L;
        String cacheProp = System.getProperty("storage.diskCache.bufferSize");
        if (cacheProp==null) {
            long maxDirectMemoryOrientMb = maxDirectMemoryMb / 3L;
            long cachSizeMb = cacheSizeMb  > maxDirectMemoryOrientMb ? maxDirectMemoryOrientMb : cacheSizeMb;
            cacheSizeMb =  (long)Math.pow(2, Math.ceil( Math.log(cachSizeMb)/ Math.log((2))));
            System.setProperty("storage.diskCache.bufferSize",Long.toString(cacheSizeMb));
            // the command below generates a NullPointerException in Orient 2.2.15-snapshot
            // OGlobalConfiguration.DISK_CACHE_SIZE.setValue(cacheSizeMb);
        }
    }