Как отслеживать использование JVM больших страниц памяти в Windows 7?

Я пытаюсь измерить прирост производительности при использовании больших страниц памяти в Windows 7 HotSpot JVM. Для этого мне необходимо отслеживать использование памяти JVM, чтобы убедиться, что большие страницы действительно используются. К сожалению, я не могу найти этого. Ниже приведено описание установок и испытаний, которые я сделал:

Настройка среды

Я использую 64-разрядную версию Windows 7 для своих тестов. "Блокировать страницы в памяти" Политика безопасности Windows включена, как описано в Поддержка Java для больших страниц памяти. Я также подтвердил, что функция "Большие страницы" включена, выполнив команду java version следующим образом:

java -XX:+UseLargePages -version

Где я получаю следующие результаты, которые посвящают функцию больших страниц:

java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)

Я использовал эту примерную программу Java из это видео во всех моих тестах, чтобы использовать всю память, доступную для кучи java:

public class InfinteStringHashmap {
public static void main(String[] args) throws Exception{
    Map<Long, String> map = new HashMap<Long, String>();

    for(long i=1; true; i++){
        StringBuilder sb = new StringBuilder();
        for(long j=0;j<i;j++) sb.append(" ");
        map.put(i, sb.toString());

        if(i % 1000 == 0){
            System.out.print(".");
            Thread.sleep(1000);
        }
    }
  }
}

Я запустил эту программу с помощью следующей команды (с фиксированным размером кучи размером 512 м):

java -Xms512m -Xmx512m -XX:+UseLargePages InfinteStringHashmap

Я также пробовал другие размеры кучи размером до 12 МБ и размером до 10 ГБ. Обратите внимание, что я запускаю свое тестовое приложение сразу после перезагрузки компьютера, чтобы убедиться, что моя свободная оперативная память не фрагментирована.

Сбой при проверке памяти

Чтобы проверить, используются ли большие страницы памяти или нет, я попытался:

  • инструмент RamMap из Windows SystInternals, который имеет специальное поле для больших страниц. Независимо от того, как я изменяю размер кучи, он не показывает использование страниц с большой памятью. Чтобы проверить это, я попробовал Создание сопоставления файлов с использованием больших страниц из MSDN, чтобы сузить возможности. Он работал отлично (он печатает размер страницы размером 2 МБ от вложенного кода). Инструмент RamMap ничего не показывает.
  • Печать размера страницы, используемого процессом Java, с использованием кода, предложенного в этом сообщении. Он печатает 4096 (размер страницы по умолчанию в Windows) все время. Чтобы проверить это, я попробовал "Большие страницы" в версии Linux JVM Hotspot, как описано в это видео, и это сработало. Однако печать размера страницы не помогла (она печатает 4096 все время).
  • Vadump инструмент, который показывает статистику виртуальной памяти о конкретном процессе. Опция "-o" должна показывать типы виртуальной машины, используемые процессом, количество используемых страниц и общий размер занятых каждым типом, который может использоваться для определения того, используются ли большие страницы. К сожалению, эта команда не работает с кодом ошибки 24, когда я устанавливаю параметр JVM UseLargePages.
  • Инструмент VmMap не обновляет отображаемый столбец памяти.
  • Простые средства мониторинга, такие как TaskManager и Perfmon, не предоставляют подробную информацию о больших страницах.

Изменить. Я пробовал следующие инструменты, которые были предложены в комментариях:

  1. Контроллер миссий Java: не предоставляет информацию о размере страницы.

  2. Проводник процессов: тот же, что и выше

Есть ли возможность измерить размер страницы процесса или контролировать использование больших страниц памяти в Windows?

Ответы

Ответ 1

Я думаю, что ваш метод тестирования не подходит. Вы используете большие страницы памяти, если хотите оптимизировать TLB:

A Translation-Lookaside Buffer (TLB) is a page translation cache that holds the most-recently used virtual-to-physical address translations. TLB is a scarce system resource. A TLB miss can be costly as the processor must then read from the hierarchical page table, which may require multiple memory accesses. By using bigger page size, a single TLB entry can represent larger memory range. There will be less pressure on TLB and memory-intensive applications may have better performance.

Вы можете использовать [JVisualVM] для профилирования своего приложения. но в случае вашего теста вы создаете новые объекты. Я не эксперт здесь, а для понимания TBL в TZ, вы должны загружать данные из памяти в структуру, которая должна находиться в буфере. Если нет, я должен быть загружен.

Теоретически тест, измеряющий время для постоянного числа операций, должен быть достаточным для того, чтобы увидеть влияние параметра VM.

Ответ 2

Я не уверен, что это то, что вы ищете.
Но procexp (Process Explorer) может оказаться полезным. Это не что-то особенное. Просто менеджер задач для Windows 7.

Кроме того, с более поздними загрузками Java JDK есть что-то, называемое Java Mission Control.

Удачи!

Ответ 3

LMP кажется особенностью определенного распределения, а не особенностью всего процесса (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs .85).aspx). Отслеживание того, какое распределение используется и которое не использует LMP, может оказаться невозможным.

Обновление: попробуйте подключить монитор системных вызовов к вашему процессу. Вы можете увидеть, вызван ли VirtualAlloc с правильными параметрами.