Sử dụng CPU quá thấp của ứng dụng Java đa luồng trên Windows

Tôi đang làm việc trên một ứng dụng Java để giải quyết một lớp các vấn đề tối ưu hóa số - chính xác hơn là các vấn đề lập trình tuyến tính quy mô lớn. Một vấn đề duy nhất có thể được chia thành các bài toán con nhỏ hơn có thể giải quyết song song. Vì có nhiều bài toán con hơn lõi CPU, tôi sử dụng ExecutorService và định nghĩa mỗi bài toán con là một Callable được gửi đến ExecutorService. Việc giải một bài toán con đòi hỏi phải gọi một thư viện riêng - một trình giải lập trình tuyến tính trong trường hợp này.

Vấn đề

Tôi có thể chạy ứng dụng trên Unix và trên các hệ thống Windows với tối đa 44 lõi vật lý và bộ nhớ lên tới 256g, nhưng thời gian tính toán trên Windows là một mức độ lớn hơn so với Linux đối với các vấn đề lớn. Windows không chỉ đòi hỏi nhiều bộ nhớ hơn mà việc sử dụng CPU theo thời gian giảm từ 25% lúc đầu xuống còn 5% sau vài giờ. Dưới đây là ảnh chụp màn hình của trình quản lý tác vụ trong Windows:

Quan sát

• Thời gian giải pháp cho các trường hợp lớn của phạm vi vấn đề tổng thể từ vài giờ đến vài ngày và tiêu tốn tới 32g bộ nhớ (trên Unix). Thời gian giải pháp cho một bài toán con nằm trong phạm vi ms.
• Tôi không gặp phải vấn đề này trên các vấn đề nhỏ mà chỉ mất vài phút để giải quyết.
• Linux sử dụng cả hai ổ cắm bên ngoài, trong khi Windows yêu cầu tôi kích hoạt rõ ràng bộ nhớ xen kẽ trong BIOS để ứng dụng sử dụng cả hai lõi. Dù không, tôi không làm điều này không ảnh hưởng đến việc sử dụng CPU nói chung theo thời gian.
• Khi tôi nhìn vào các luồng trong VisualVM, tất cả các luồng pool đang chạy, không có chuỗi nào đang chờ hoặc khác.
• Theo VisualVM, 90% thời gian CPU dành cho một cuộc gọi chức năng gốc (giải quyết một chương trình tuyến tính nhỏ)
• Bộ sưu tập rác không phải là một vấn đề vì ứng dụng không tạo và hủy tham chiếu rất nhiều đối tượng. Ngoài ra, hầu hết bộ nhớ dường như được phân bổ ngoài heap. 4g heap là đủ trên Linux và 8g trên Windows trong trường hợp lớn nhất.

Những gì tôi đã thử

• tất cả các loại đối số JVM, XMS cao, metaspace cao, cờ UseNUMA, các GC khác.
• các JVM khác nhau (Hotspot 8, 9, 10, 11).
• các thư viện riêng khác nhau của các bộ giải lập trình tuyến tính khác nhau (CLP, Xpress, Cplex, Gurobi).

Câu hỏi

• Điều gì thúc đẩy sự khác biệt về hiệu năng giữa Linux và Windows của một ứng dụng Java đa luồng lớn, sử dụng nhiều cuộc gọi gốc?
• Có bất cứ điều gì mà tôi có thể thay đổi trong quá trình triển khai sẽ giúp Windows, chẳng hạn, tôi có nên tránh sử dụng ExecutorService nhận hàng ngàn Callables và thay vào đó làm gì không?

Đối với Windows, số lượng luồng trên mỗi quy trình bị giới hạn bởi không gian địa chỉ của quy trình (xem thêm Mark Russinovich - Đẩy các giới hạn của Windows: Quy trình và Chủ đề ). Hãy nghĩ rằng điều này gây ra tác dụng phụ khi gần đến giới hạn (làm chậm các chuyển đổi ngữ cảnh, phân mảnh ...). Đối với Windows, tôi sẽ cố gắng phân chia tải công việc cho một tập hợp các quy trình. Đối với một vấn đề tương tự mà tôi đã có từ nhiều năm trước, tôi đã triển khai một thư viện Java để thực hiện việc này thuận tiện hơn (Java 8), hãy xem nếu bạn thích: Thư viện để sinh ra các tác vụ trong một quy trình bên ngoài .

Âm thanh như cửa sổ đang lưu một số bộ nhớ vào pagefile, sau khi nó không được xử lý trong một thời gian và đó là lý do tại sao CPU bị tắc nghẽn bởi tốc độ Đĩa

Bạn có thể xác minh nó với Process explorer và kiểm tra dung lượng bộ nhớ được lưu trữ

Tôi nghĩ rằng sự khác biệt hiệu suất này là do cách hệ điều hành quản lý các luồng. JVM ẩn tất cả sự khác biệt của hệ điều hành. Có rất nhiều trang web mà bạn có thể đọc về nó, ví dụ như thế này . Nhưng nó không có nghĩa là sự khác biệt biến mất.

Tôi cho rằng bạn đang chạy trên Java 8+ JVM. Do thực tế này, tôi khuyên bạn nên thử sử dụng các tính năng lập trình luồng và chức năng. Lập trình hàm rất hữu ích khi bạn có nhiều vấn đề độc lập nhỏ và bạn muốn dễ dàng chuyển từ thực hiện tuần tự sang thực thi song song. Tin vui là bạn không phải xác định chính sách để xác định số lượng luồng bạn phải quản lý (như với ExecutorService). Ví dụ (lấy từ đây ):

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);
    }

}

Kết quả:

Đối với các luồng thông thường, phải mất 1 phút 10 giây. Đối với các luồng song song, phải mất 23 giây. PS đã thử nghiệm với i7-7700, RAM 16G, 10

Vì vậy, tôi khuyên bạn nên đọc về lập trình hàm, luồng, hàm lambda trong Java và thử thực hiện một số lượng thử nghiệm nhỏ với mã của bạn (được điều chỉnh để hoạt động trong ngữ cảnh mới này).

Bạn vui lòng gửi số liệu thống kê hệ thống? Trình quản lý tác vụ đủ tốt để cung cấp một số đầu mối nếu đó là công cụ duy nhất có sẵn. Nó có thể dễ dàng biết liệu các nhiệm vụ của bạn có đang chờ IO hay không - nghe có vẻ là thủ phạm dựa trên những gì bạn mô tả. Nó có thể là do vấn đề quản lý bộ nhớ nhất định hoặc thư viện có thể ghi một số dữ liệu tạm thời vào đĩa, v.v.

Khi bạn nói 25% mức sử dụng CPU, bạn có nghĩa là chỉ có một vài lõi bận rộn làm việc cùng một lúc? (Có thể là tất cả các lõi hoạt động theo thời gian, nhưng không đồng thời.) Bạn có kiểm tra xem có bao nhiêu luồng (hoặc quy trình) thực sự được tạo trong hệ thống không? Là số luôn luôn lớn hơn số lượng lõi?

Nếu có đủ chủ đề, nhiều người trong số họ đang chờ đợi một cái gì đó? Nếu đúng, bạn có thể thử ngắt (hoặc đính kèm trình gỡ lỗi) để xem những gì họ đang chờ đợi.