W kontekście miękkiego systemu czasu rzeczywistego, który nie powinien zatrzymywać się na dłużej niż 200 ms, Szukamy sposobu, aby uzyskać wcześniejsze ostrzeżenie przed zbliżającym się pełnym GC. Zdajemy sobie sprawę, że możemy nie być w stanie tego uniknąć, ale chcielibyśmy przejść do innego węzła, zanim system się zawiesza.Otrzymywanie ostrzeżenia z wyprzedzeniem przed pełnym GC
Udało nam się wymyślić schemat, który zapewni nam wcześniejsze ostrzeżenie przed nadejściem pełnej wartości GC, co może spowodować zatrzymanie systemu na kilka sekund (czego musimy unikać).
To, co udało nam się wymyślić, opiera się na statystykach darmowej listy CMS: -XX:PrintFLSStatistics=1. To drukuje statystykę z listy darmowej do dziennika GC po każdym cyklu GC, w tym młodym GC, więc informacje są dostępne w krótkich odstępach czasu i będą pojawiać się jeszcze częściej w odstępach o wysokiej alokacji pamięci. Prawdopodobnie kosztuje trochę pod względem wydajności, ale naszym roboczym założeniem jest to, że możemy sobie na to pozwolić.
Wyjście do dziennika wygląda tak:
Statistics for BinaryTreeDictionary:
------------------------------------
Total Free Space: 382153298
Max Chunk Size: 382064598
Number of Blocks: 28
Av. Block Size: 13648332
Tree Height: 8
W szczególności, maksymalna wielkość wolny kawałek jest 382064598 słowa. W przypadku słów 64-bitowych wartość ta powinna wynosić nieco poniżej 2915 MB. Liczba ta zmniejsza się bardzo powoli, z szybkością około 1 MB na godzinę.
Rozumiemy, że tak długo, jak maksymalny rozmiar wolnej części jest większy niż młode pokolenie (zakładając, że nie ma humidystycznego przydzielania obiektów), każda promocja obiektu powinna odnieść sukces.
Niedawno przeprowadziliśmy kilkutygodniowe testy obciążeniowe i zauważyliśmy, że CMS był w stanie utrzymać maksymalne porcje w górę w stosunku do 94% całkowitej przestrzeni starego regionu. Wydaje się, że maksymalny rozmiar porcji maleje z szybkością mniejszą niż 1 MB/godz., Co powinno być w porządku - w związku z tym nie dojdziemy do pełnego GC w najbliższym czasie, a serwery najprawdopodobniej zostaną wyłączone z powodu konserwacji więcej często może wystąpić pełny GC.
W poprzednim teście, w czasie, gdy system był mniej wydajny pod względem pamięci, byliśmy w stanie uruchomić system na dobre 10 godzin. W ciągu pierwszej godziny maksymalny rozmiar wolnej części zmniejszył się do 100 MB, gdzie pozostał przez ponad 8 godzin. W ciągu ostatnich 40 minut biegu maksymalny rozmiar wolnej części spadł ze stałą prędkością w kierunku 0, gdy wystąpił pełny GC - było to bardzo zachęcające, ponieważ w przypadku tego obciążenia wydawało się, że jesteśmy w stanie uzyskać 40-minutowy postęp ostrzeżenie (gdy wielkość porcji zaczęła się zmniejszać w kierunku 0).
Moje pytanie do was: zakładając, że to wszystko odzwierciedla obciążenia długotrwałego obciążenia szczytowego (w danym punkcie w czasie produkcji będzie tylko niższe), to brzmi jak ważny podejście? Do jakiego stopnia niezawodności liczycie, że powinniśmy móc liczyć na maksymalną statystykę rozmiaru porcji z dziennika GC?
Jesteśmy zdecydowanie otwarci na sugestie, ale prosimy o ograniczenie ich do rozwiązań dostępnych w HotSpot (przynajmniej dla nas Azul, przynajmniej na razie). Również G1 samo w sobie nie jest rozwiązaniem, chyba że możemy wymyślić podobną metrykę, która da nam wcześniejsze ostrzeżenie przed Pełnymi OW lub dowolnymi OW, które znacznie przewyższają naszą SLA (i czasami mogą się zdarzyć).
Czy możliwe jest przetestowanie JRockit Deterministic GC? http://docs.oracle.com/cd/E15289_01/doc.40/e15071/intro.htm#i1010645 – fglez
Jesteśmy tego świadomi, podobnie jak inne oferty IBM w czasie rzeczywistym i Oracle. Ważne jest, abyśmy mieli słabsze gwarancje (lub nawet heurystyki), które umożliwiają nam wdrożenie również w HotSpot. – nadavwr
Czy rozważałeś wymuszenie okresowego pełnego GC na naprzemiennych węzłach? To pozwoliłoby na bardziej przewidywalne zachowanie. CMS nie jest przewidywalny w dłuższej perspektywie w miarę rozrastania się fragmentacji. – fglez