NUMA nhận thức về JVM

Question

Câu hỏi của tôi liên quan đến mức độ ứng dụng JVM có thể khai thác bố cục NUMA của máy chủ.

Tôi có một ứng dụng Akka trong đó các tác nhân đồng thời xử lý các yêu cầu bằng cách kết hợp dữ liệu đến với dữ liệu 'phổ biến' đã được nạp vào một đối tượng bất biến (Scala). Ứng dụng mở rộng tốt trên đám mây, sử dụng nhiều máy ảo lõi kép, nhưng hoạt động kém trên một máy tính 64 lõi đơn. Tôi đoán điều này là vì đối tượng dữ liệu chung nằm trong một ô NUMA và nhiều luồng đồng thời truy cập từ các ô khác là quá nhiều cho các kết nối.

Nếu tôi chạy 64 ứng dụng JVM riêng biệt, mỗi ứng dụng chứa 1 tác nhân thì hiệu suất lại tốt. Một phương pháp tiếp cận vừa phải có thể là chạy nhiều ứng dụng JVM vì có NUMA ô (8 trong trường hợp của tôi), cho hệ điều hành máy chủ có cơ hội giữ các luồng và bộ nhớ với nhau?

Nhưng có cách nào thông minh hơn để đạt được hiệu ứng tương tự trong một JVM đơn lẻ không? Ví dụ. nếu tôi thay thế đối tượng dữ liệu chung của mình bằng một vài trường hợp của một kiểu chữ, JVM có khả năng đặt chúng trên ô NUMA tối ưu không?

Cập nhật:

Tôi đang sử dụng Oracle JDK 1.7.0_05, và Akka 2.1.4

bây giờ tôi đã thử với các tùy chọn UseNUMA và UseParallelGC JVM. Dường như không có bất kỳ tác động đáng kể nào đến hiệu suất chậm khi sử dụng một hoặc một vài JVM. Tôi cũng đã thử sử dụng một PinnedDispatcher và thre-pool-executor không có hiệu lực. Tôi không chắc chắn nếu cấu hình có hiệu lực mặc dù, vì có vẻ như không có gì khác nhau trong các bản ghi khởi động.

Cải tiến lớn nhất vẫn còn khi tôi sử dụng một JVM đơn cho mỗi công nhân (~ 50). Tuy nhiên, vấn đề với điều này dường như là có một sự chậm trễ dài (lên đến một vài phút) trước khi FailureDector đăng ký trao đổi thành công 'nhịp tim đầu tiên' giữa các JVM của Akka cluster. Tôi nghi ngờ có một số vấn đề khác ở đây mà tôi chưa phát hiện ra. Tôi đã có để tăng ulimit -u kể từ khi tôi đã nhấn số lượng tối đa mặc định của các quy trình (1024).

Chỉ cần làm rõ, tôi không cố gắng đạt được số lượng lớn thư, chỉ cần cố gắng có nhiều diễn viên riêng đồng thời truy cập một đối tượng bất biến.

Answer 1

Tôi nghĩ rằng nếu bạn chắc chắn rằng các vấn đề không có trong thuật toán xử lý tin nhắn thì bạn nên tính đến không chỉ tùy chọn NUMA mà còn cả env. Cấu hình, bắt đầu từ phiên bản JVM (mới nhất là tốt hơn, Oracle JDK cũng hoạt động tốt hơn OpenJDK), sau đó là các tùy chọn JVM (bao gồm GC, bộ nhớ, các tùy chọn đồng thời, vv), sau đó các phiên bản Scala và Akka (các ứng cử viên phát hành mới nhất và các mốc quan trọng có thể tốt hơn nhiều) và cả cấu hình Akka nữa.

Từ here bạn có thể mượn tất cả những thứ quan trọng cần có 50M messages per second of total throughput for Akka actors on contemporary laptops.

Không bao giờ có cơ hội chạy các điểm chuẩn này trên máy chủ 64 lõi - vì vậy mọi phản hồi sẽ được đánh giá cao.

Từ những phát hiện của tôi, có thể giúp, việc triển khai hiện tại của ForkJoinPool làm tăng thời gian gửi thư khi số lượng chủ đề trong nhóm tăng lên. Nó rất đáng chú ý đối với các trường hợp khi tỷ lệ cuộc gọi yêu cầu phản hồi giữa các tác nhân là cao, e. g. trên máy tính xách tay của tôi khi tăng kích thước hồ bơi từ 4 đến 64 tin nhắn gửi độ trễ của các diễn viên Akka cho các trường hợp như vậy tăng lên đến 2-3 lần đối với hầu hết các dịch vụ thực thi (Scala's ForkJoinPool, JDK's ForkJoinPool, ThreadPoolExecutor).

Bạn có thể kiểm tra xem có bất kỳ khác biệt nào không bằng cách chạy mvnAll.sh với biến hệ thống benchmark.parallelism được đặt thành các giá trị khác nhau.