Windows переменная среды NUMBER_OF_PROCESSORS показывает разные значения внутри JVM и за ее пределами - PullRequest
Новая
       223

Windows переменная среды NUMBER_OF_PROCESSORS показывает разные значения внутри JVM и за ее пределами

3 голосов
/ 08 мая 2020

На нашем Windows Server 2019 у нас 36 ядер и 72 логических процессора, как показано в окне производительности ЦП диспетчера задач. А также, если из командной строки, если я запустил команду. 

echo %NUMBER_OF_PROCESSORS%

Он сообщает мне 72.

Однако изнутри программы Java, если я запустил следующий код snippet, 

public class NoOfCPUs {  
    public static void main(String[] args) {
        String envName = "NUMBER_OF_PROCESSORS";
        String noOfP = System.getenv(envName);
        System.out.format("%s (from env) = %s%n", envName, noOfP);
    }
}

вывод выглядит следующим образом: 

NUMBER_OF_PROCESSORS (from env) = 36

Скомпилировано с помощью 64-разрядного Java 8 компилятора на Windows в IDE Netbeans. Сделал исполняемый jar. Запустите банку, как: 

java -jar NoOfCPUs.jar

Та же переменная системной среды, NUMBER_OF_PROCESSORS показывает мне другой результат из командной строки и из программы Java.

Почему?

Это из-за группы логических процессоров, которую Windows использует после версии 2009 года? Группа логических процессоров содержит максимум 64 процессора в группе.

1 Ответ

2 голосов
/ 08 мая 2020

Кажется, это связано с другими вопросами, например:

, и в этом отчете об ошибке говорится, что он не будет поддерживаться (не исправит):

https://bugs.openjdk.java.net/browse/JDK-6942632

В отчете об ошибке говорится, что пользователь должен нести ответственность за настройку правильного количества ЦП на Java, это возможно с:

  1. https://bitsum.com/portfolio/groupextend/
  2. Возможно другие из-за наследования аффинности, например start / affinity, см. этот ответ , но я не могу проверить / подтвердить, потому что у моего ноутбука их не так много ядер

Я думаю, вам следует рассмотреть возможность запуска нескольких экземпляров вашего приложения (и Java) вместо одного, чтобы в любом случае добиться максимальной производительности из-за локальности NUMA, хотя разные Java Виртуальные машины имеют поддержка NUMA он все еще может иметь масштабируемость. в зависимости от настроенного алгоритма сборки мусора (не параллельного, таким образом, Stop-the-World) см. Sun / Oracle) вы можете захотеть взглянуть на другую Java виртуальную машину OpenJ9 (от IBM) и другие, например Azul Zing JVM

Если это Windows с указанием c limit, вы можете рассмотреть возможность перехода на другую операционную систему или запуска нескольких экземпляров Windows через гипервизор по вашему выбору.

...