Znajomość NUMA JVM

Question

Moje pytanie dotyczy zakresu, w jakim aplikacja JVM może wykorzystać układ NUMA hosta.

Mam aplikację Akka, w której aktorzy jednocześnie przetwarzają żądania, łącząc przychodzące dane z "zwykłymi" danymi już załadowanymi do niezmiennego obiektu (Scala). Aplikacja skaluje się dobrze w chmurze, wykorzystując wiele dwurdzeniowych maszyn wirtualnych, ale działa słabo na pojedynczym komputerze z 64 rdzeniami. Zakładam, że dzieje się tak dlatego, że wspólny obiekt danych znajduje się w jednej komórce NUMA, a wiele wątków współbieżnie uzyskujących dostęp z innych komórek jest zbyt duże dla interkonektów.

Jeśli uruchomię 64 oddzielne aplikacje JVM, z których każda zawiera 1 aktora, wówczas wydajność znów będzie dobra. Bardziej umiarkowanym podejściem może być uruchamianie tylu aplikacji JVM, ile jest komórek NUMA (w moim przypadku 8), co daje systemowi głównemu możliwość zachowania wątków i pamięci razem?

Ale czy istnieje mądrzejszy sposób uzyskania tego samego efektu w ramach pojedynczej maszyny JVM? Na przykład. gdybym zastąpił mój wspólny obiekt danych kilkoma instancjami klasy case, czy JVM miałaby możliwość umieszczenia ich na optymalnej komórce NUMA?

Aktualizacja:

Używam Oracle JDK 1.7.0_05 i Akka 2.1.4

mam teraz próbował z opcjami UseNUMA i UseParallelGC JVM. Wydaje się, że żaden z nich nie miał znaczącego wpływu na powolną wydajność przy korzystaniu z jednej lub kilku maszyn JVM. Próbowałem również używać PinnedDispatcher i executora puli thre-pool bez żadnego efektu. Nie jestem pewien, czy konfiguracja ma wpływ, ponieważ nie wydaje się nic innego w dziennikach uruchamiania.

Największa poprawa pozostaje, gdy używam pojedynczej maszyny JVM na pracownika (~ 50). Jednak problem z tym wydaje się, że istnieje długie opóźnienie (do kilku minut), zanim FailureDector zarejestruje pomyślną wymianę "pierwszego pulsu" pomiędzy JVM klastra Akka. Podejrzewam, że jest jeszcze inny problem, którego jeszcze nie odkryłem. Musiałem już zwiększyć ulimit -u, ponieważ osiągnąłem domyślną maksymalną liczbę procesów (1024).

Aby wyjaśnić, nie próbuję osiągnąć dużej liczby wiadomości, tylko próbuję mieć wielu oddzielnych aktorów jednocześnie uzyskujących dostęp do niezmiennych obiektów.

Answer 1

Myślę, że jeśli masz pewność, że problemy nie występują w algorytmach przetwarzania wiadomości, powinieneś wziąć pod uwagę nie tylko opcję NUMA, ale całe środowisko. konfiguracja, zaczynając od wersji JVM (najnowszy jest lepszy, Oracle JDK również w większości działa lepiej niż OpenJDK), następnie opcje JVM (w tym GC, pamięć, opcje współbieżności itp.), a następnie wersje Scala i Akka (najnowsze wersje i kamienie milowe mogą być znacznie lepsze) a także konfiguracja Akka.

Od here możesz pożyczyć wszystkie rzeczy, które mają znaczenie, aby uzyskać 50M messages per second of total throughput for Akka actors on contemporary laptops.

Nigdy nie udało się uruchomić tych testów porównawczych na 64-rdzeniowym serwerze - więc wszelkie opinie będą bardzo mile widziane.

Z moich ustaleń, które mogą pomóc, obecne implementacje ForkJoinPool zwiększają opóźnienie wysyłania wiadomości, gdy zwiększa się liczba wątków w puli. Jest to bardzo zauważalne w przypadkach, gdy wskaźnik wezwania na żądanie pomiędzy aktorami jest wysoki, np. sol. na moim laptopie przy zwiększaniu rozmiaru puli od 4 do 64 wiadomości opóźnienie aktorów Akka dla takich przypadków rośnie do 2-3 razy dla większości usług wykonawców (Scala's ForkJoinPool, JDK's ForkJoinPool, ThreadPoolExecutor).

Możesz sprawdzić, czy są jakieś różnice, uruchamiając mvnAll.sh ze zmienną systemową benchmark.parallelism ustawioną na różne wartości.