Czy ktoś może wyjaśnić, jakie są opcje JVM ReservedCodeCacheSizei jakie InitialCodeCacheSizesą? W szczególności, kiedy / dlaczego miałbym chcieć to zmienić? Jak zdecydować, jaki jest właściwy rozmiar?
Oto, co mówią doktorzy:
-XX: ReservedCodeCacheSize = 32m Zarezerwowany rozmiar pamięci podręcznej kodu (w bajtach) - maksymalny rozmiar pamięci podręcznej kodu. [Solaris 64-bitowy, amd64 i -server x86: 2048m; w wersji 1.5.0_06 i wcześniejszych, Solaris 64-bit i and64: 1024m.]
Odpowiedzi:
ReservedCodeCacheSize(i InitialCodeCacheSize) jest opcją dla kompilatora (just-in-time) maszyny wirtualnej Java Hotspot. Zasadniczo ustawia maksymalny rozmiar pamięci podręcznej kodu kompilatora.
Pamięć podręczna może się zapełnić, co powoduje ostrzeżenia, takie jak następujące:
Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792
Jest znacznie gorzej, gdy następuje Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.
Kiedy ustawić tę opcję?
Zwykle nie zmieniałbyś tej wartości. Myślę, że wartości domyślne są dość dobrze wyważone, ponieważ te problemy występują tylko w bardzo rzadkich przypadkach (w moim doświadczeniu).
Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and amd64: 1024m.]Nie znam wartości OpenJDK. Umiarkowany wzrost powinien być wystarczający (wcześniejsze ustawienie 1024 m było poza dobrem i złem).
@jeha odpowiada na wszystko, co chciałem wiedzieć z tego pytania, poza tym, na jaką wartość ustawić parametry. Ponieważ nie napisałem kodu, który wdrażałem, nie miałem dużego wglądu w ilość pamięci, którą miał.
Możesz jednak użyć jconsole, aby podłączyć się do uruchomionego procesu Java, a następnie użyć karty „Pamięć”, aby sprawdzić rozmiar pamięci podręcznej kodu. Aby uzyskać kompletność, kroki są następujące (środowisko Linux VM, chociaż jestem pewien, że inne środowiska są podobne):
Ponownie, może to zająć kilka chwil, zanim ekran się odświeży, a następnie powinieneś zobaczyć coś takiego:
Jak widać, moja pamięć podręczna kodu zajmuje około 49 MB. W tym momencie nadal miałem wartość domyślną, która według dokumentacji (i @jeha) wynosi 48 MB. Z pewnością była to dla mnie wielka motywacja do zwiększenia oprawy!
Ben.
Domyślnie 1024 MB prawdopodobnie było przesadzone, ale domyślnie 48 MB wydaje się to robić za mało ...
Dobre doświadczenie zdobyte przez zespół inżynierów Indeed i wyzwania, jakie napotkali podczas migracji do jdk 8.
http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/
Wniosek: JDK 8 potrzebuje więcej pamięci podręcznej kodu niż JDK 7
Domyślny rozmiar pamięci podręcznej kodeków dla środowiska JRE 8 wynosi około 250 MB, czyli około pięć razy większy niż domyślny 48 MB dla środowiska JRE 7. Z naszego doświadczenia wynika, że środowisko JRE 8 potrzebuje tego dodatkowego bufora kodeków. Jak dotąd przerzuciliśmy około dziesięciu usług na JRE 8 i wszystkie używają około czterokrotnie więcej kodeków niż poprzednio.
z https://blogs.oracle.com/poonam/entry/why_do_i_get_message :
Poniżej przedstawiono dwa znane problemy w jdk7u4 + związane z opróżnianiem CodeCache:
- Kompilator może nie zostać ponownie uruchomiony, nawet gdy zajętość CodeCache spadnie do prawie połowy po awaryjnym opróżnieniu.
- Opróżnianie awaryjne może spowodować wysokie użycie procesora przez wątki kompilatora, co prowadzi do ogólnego pogorszenia wydajności.
Ten problem z wydajnością i problem polegający na tym, że kompilator nie jest ponownie włączany, został rozwiązany w JDK8. Aby obejść te problemy w JDK7u4 +, możemy zwiększyć rozmiar pamięci podręcznej kodu za pomocą opcji ReservedCodeCacheSize, ustawiając ją na wartość większą niż ślad skompilowanego kodu, tak aby CodeCache nigdy się nie zapełniło. Innym rozwiązaniem tego problemu jest wyłączenie opróżniania CodeCache za pomocą opcji -XX: -UseCodeCacheFlushing JVM.
Powyższe problemy zostały naprawione w JDK8 i jego aktualizacjach.
Dlatego warto wspomnieć o tych informacjach w przypadku systemów działających na JDK 6 (z wyłączonym opróżnianiem kodu) i 7.