Занадто низьке використання процесора багатопотокової програми Java для Windows

Я працюю над додатком Java для вирішення класу задач з числовою оптимізацією - більш точні проблеми лінійного програмування. Одну проблему можна розділити на менші підпрограми, які можна вирішити паралельно. Оскільки є більше підпроблем, ніж ядер CPU, я використовую ExecutorService і визначаю кожну підпроблему як Callable, який надсилається до ExecutorService. Розв’язання підпрограми вимагає виклику рідної бібліотеки - лінійки, що вирішує програмування, у цьому випадку.

Проблема

Я можу запускати додаток в Unix та в системах Windows з об'ємом до 44 фізичних ядер і до 256 г пам'яті, але час обчислень у Windows на порядок вище, ніж у Linux для великих проблем. Windows не тільки вимагає значно більше пам’яті, але використання процесора з часом падає з 25% на початку до 5% через кілька годин. Ось скріншот менеджера завдань у Windows:

Спостереження

• Час вирішення великих випадків загальної проблеми становить від години до дня і вимагає до 32 г пам'яті (на Unix). Час рішення підпроблеми знаходиться в діапазоні мс.
• Я не стикаюся з цим питанням щодо невеликих проблем, на вирішення яких потрібно лише кілька хвилин.
• Linux використовує обидва сокети поза коробкою, тоді як Windows вимагає від мене явно активувати переплетення пам'яті в BIOS, щоб програма використовувала обидва ядра. Не робити це я не впливає на погіршення загального використання процесора з часом.
• Коли я дивлюсь на потоки в VisualVM, всі потоки пулу запущені, жодна не очікує або ще.
• Згідно з VisualVM, 90% часу процесора витрачається на виклик нативної функції (вирішення невеликої лінійної програми)
• Збір сміття не є проблемою, оскільки додаток не створює та не відсилає посилання на багато об’єктів. Крім того, більшість пам’яті, здається, виділяється поза грою. 4 г купи достатньо для Linux і 8 г для Windows для найбільшого екземпляра.

Що я спробував

• всілякі аргументи JVM, високий XMS, високий метапростір, прапор UseNUMA, інші GC.
• різні JVM (Точка 8, 9, 10, 11).
• різні рідні бібліотеки різних рішень лінійного програмування (CLP, Xpress, Cplex, Gurobi).

Запитання

• Що визначає різницю продуктивності між Linux та Windows великого багатопотокового додатку Java, який широко використовує вбудовані дзвінки?
• Чи можу я змінити впровадження, що могло б допомогти Windows, наприклад, чи слід уникати використання ExecutorService, який отримує тисячі викликів, і робити що замість цього?

Для Windows кількість потоків на процес обмежена адресним простором процесу (див. Також Марк Русинович - Проштовхування меж Windows: Процеси та нитки ). Подумайте, що це викликає побічні ефекти, коли воно наближається до меж (уповільнення переключення контексту, фрагментація ...). Для Windows я б спробував розділити робоче навантаження на набір процесів. Для подібної проблеми, яку я мав років тому, я застосував бібліотеку Java, щоб зробити це зручніше (Java 8), погляньте, якщо вам подобається: Бібліотека для нерестування завдань у зовнішньому процесі .

Здається, що Windows кешує деяку пам’ять у файлі сторінки, після того, як протягом деякого часу його не торкається, і ось чому процесор обмежується швидкістю диска

Ви можете перевірити це за допомогою Провідника процесів і перевірити, скільки пам’яті збережено в кеші

Я думаю, що ця різниця в продуктивності пов'язана з тим, як ОС управляє потоками. JVM приховає всю різницю в ОС. Є багато сайтів, де ви можете прочитати про це, наприклад це , наприклад. Але це не означає, що різниця зникає.

Я думаю, ви працюєте на Java 8+ JVM. У зв'язку з цим фактом я пропоную вам спробувати використовувати функції потокового та функціонального програмування. Функціональне програмування дуже корисно, коли у вас є багато маленьких незалежних проблем і ви хочете легко перейти від послідовного до паралельного виконання. Хороша новина полягає в тому, що вам не потрібно визначати політику, щоб визначити, скільки потоків потрібно керувати (як, наприклад, з ExecutorService). Просто для прикладу (взято звідси ):

package com.mkyong.java8;

import java.util.ArrayList;
import java.util.List;
import java.util.stream.IntStream;
import java.util.stream.Stream;

public class ParallelExample4 {

    public static void main(String[] args) {

        long count = Stream.iterate(0, n -> n + 1)
                .limit(1_000_000)
                //.parallel()   with this 23s, without this 1m 10s
                .filter(ParallelExample4::isPrime)
                .peek(x -> System.out.format("%s\t", x))
                .count();

        System.out.println("\nTotal: " + count);

    }

    public static boolean isPrime(int number) {
        if (number <= 1) return false;
        return !IntStream.rangeClosed(2, number / 2).anyMatch(i -> number % i == 0);
    }

}

Результат:

Для звичайних потоків потрібно 1 хвилина 10 секунд. Для паралельних потоків потрібно 23 секунди. PS Тестується з i7-7700, 16G ОЗУ, WIndows 10

Отож, я пропоную вам прочитати про програмування функцій, потік, функцію лямбда на Java та спробувати впровадити невелику кількість тестів зі своїм кодом (адаптованим для роботи в новому контексті).

Будь ласка, опублікуйте статистику системи? Диспетчер завдань достатньо хороший, щоб надати певну підказку, якщо це єдиний доступний інструмент. Це може легко визначити, чи чекають ваші завдання на IO - це звучить як винуватець на основі того, що ви описали. Це може бути пов'язано з певним питанням управління пам'яттю, або бібліотека може записати на диск деякі тимчасові дані тощо.

Коли ви говорите про 25% використання процесора, ви маєте на увазі, що лише кілька ядер зайняті роботою одночасно? (Можливо, час від часу всі ядра працюють, але не одночасно.) Чи перевірили б ви, скільки потоків (або процесів) справді створено в системі? Чи число завжди більше, ніж кількість ядер?

Якщо ниток достатньо, чи багато з них в режимі очікування чогось чекають? Якщо це правда, ви можете спробувати перервати (або приєднати налагоджувач), щоб побачити, що їх чекає.