Мониторинг использования памяти без кучи JVM

Ответ 1

Ваша куча фактически использует 6.5 ГБ виртуальной памяти (это может включать в себя perm gen)

У вас есть куча потоков с использованием стеков 64 МБ. Непонятно, почему некоторые из них и другие используют по умолчанию 1 МБ.

Общее количество виртуальной памяти составляет 9,3 млн. КБ. Я бы только беспокоился о размере резидента.

Попробуйте использовать top, чтобы найти резидентный размер процесса.

Вы можете найти эту программу полезной

    BufferedReader br = new BufferedReader(new FileReader("C:/dev/gistfile1.txt"));
    long total = 0;
    for(String line; (line = br.readLine())!= null;) {
        String[] parts = line.split("[- ]");
        long start = new BigInteger(parts[0], 16).longValue();
        long end = new BigInteger(parts[1], 16).longValue();
        long size = end - start + 1;
        if (size > 1000000)
            System.out.printf("%,d : %s%n", size, line);
        total += size;
    }
    System.out.println("total: " + total/1024);

Если у вас нет библиотеки JNI, использующей память, я предполагаю, что у вас много потоков, каждая из которых имеет собственное пространство стека. Я бы проверил количество потоков, которые у вас есть. Вы можете уменьшить максимальное количество стека на поток, но лучшим вариантом может быть сокращение количества потоков, которые у вас есть.

Память выключенной памяти по определению неуправляема, поэтому ее нелегко "настроить" как таковую. Даже настройка кучи не простая.

Размер стека по умолчанию для 64-битных JVM составляет 1024 КБ, поэтому 700 потоков будут использовать 700 МБ виртуальной памяти.

Не следует путать размеры виртуальной памяти для размеров резидентной памяти. Виртуальная память в 64-битном приложении почти бесплатна, и вам нужен только резидентный размер.

Как я вижу, у вас всего 9,3 ГБ.

• Куча 6.0 ГБ.
• 128 MB perm gen
• 700 МБ стеков.
• < 250 разделяемых библиотек
• 2.2 ГБ неизвестной (я подозреваю, что виртуальная память не является резидентной памятью)

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

Хммм каждая из этих пар является потоком.

7f0cffddf000-7f0cffedd000 rw-p 00000000 00:00 0 
7f0cffedd000-7f0cffee0000 ---p 00000000 00:00 0

и они предполагают, что теперь у вас чуть меньше 700 потоков.

Ответ 2

Достаточно удобный способ контроля (и частичного изменения) параметров среды выполнения экземпляра JVM - это VisualVM:

• Домашняя страница VisualVM
• Документы Oracle VisualVM

PS
(Удалена)

ПФС Я вспомнил другой инструмент, который я использовал некоторое время назад: Visual GC. Он показывает вам визуально подробно, что происходит внутри управления памятью JVM, здесь некоторые скриншоты. Очень мощный, и его можно даже интегрировать с плагином в VisualVM (см. Раздел плагинов на главной странице VisualVM).

PPPS
We sometimes have anormaly long pauses, up to 20 seconds. [...] I guess the pauses could be a full GC on a swapped heap right?
Да, это возможно. Эти длительные паузы могут быть вызваны полным GC даже на необработанных кучах. С VisualVM вы можете отслеживать, будет ли полный GC в момент паузы ~ 20 секунд. Я предлагаю запустить VisualVM на другом хосте и подключить его к процессу JVM на вашем виртуальном сервере через явный JMX, чтобы не фальсифицировать измерения с помощью дополнительная нагрузка. Вы можете оставить эту установку за несколько дней/недель и, следовательно, собрать окончательную информацию об этом явлении.

Afaics с текущей информацией, на данный момент есть только следующие возможности:

• наблюдаемые паузы происходят одновременно с полным GC: JVM настроен неправильно. Вы можете облегчить это с помощью параметров JVM и, возможно, выбрать другой алгоритм/движок GC (вы пробовали CMS и G1 GC? Подробнее о том, как это происходит, например, здесь)
• наблюдаемые паузы не совпадают с полным GC в JVM: причиной может быть физический виртуальный хост. Проверьте свои SLA (сколько виртуальной оперативной памяти гарантировано находится в физической памяти) и обратитесь к поставщику услуг, запрашивающему мониторинг виртуального сервера.

Я должен был упомянуть, что VisualVM поставляется с Java. И JConsole, также поставляемый с Java, который легче и компактнее VisualVM (но не имеет плагинов, без профилирования и т.д.), Но дает аналогичный обзор.

Если настройка JMX-соединения для VisualVM/JConsole/VisualGC слишком сложна на данный момент, вы можете прибегнуть к параметрам java файла: -XX:+PrintGC -XX:+PrintGCTimeStamps -Xloggc:/my/log/path/gclogfile.log. Эти параметры заставят JVM записывать в указанный файл журнала запись для каждого запуска GC. Этот вариант также хорошо подходит для долгосрочного анализа и, вероятно, является одним из наименьших издержек на вашем JVM.

Снова подумав (и снова) о вашем вопросе: если вы задаетесь вопросом, откуда возникают дополнительные 3+ GB, вот вопрос . Я лично использую коэффициент x1.5 как правило большого пальца.