Может кто - то пожалуйста , объясните , какой вариант JVM ReservedCodeCacheSizeи InitialCodeCacheSizeесть? В частности, когда и зачем мне его менять? Как мне выбрать правильный размер?
Вот что говорят документы:
-XX: ReservedCodeCacheSize = 32m Зарезервированный размер кэша кода (в байтах) - максимальный размер кэша кода. [Solaris 64-бит, amd64 и -сервер x86: 2048m; в 1.5.0_06 и более ранних версиях Solaris 64-bit и and64: 1024m.]
Ответы:
ReservedCodeCacheSize(и InitialCodeCacheSize) - это опция для (своевременного) компилятора виртуальной машины Java Hotspot. По сути, он устанавливает максимальный размер кеша кода компилятора.
Кеш может переполниться, что приводит к следующим предупреждениям:
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
Намного хуже, когда за ним следует Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.
Когда устанавливать эту опцию?
Обычно вы не меняете это значение. Я думаю, что значения по умолчанию довольно хорошо сбалансированы, потому что эти проблемы возникают только в очень редких случаях (по моему опыту).
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.]не знаю значений OpenJDK. Умеренного увеличения должно быть достаточно (ранее установка 1024м была выше добра и зла).
@jeha отвечает на все, что я хотел узнать из этого вопроса, кроме того, какое значение установить для параметров. Поскольку я не писал код, который развертывал, у меня не было особого представления о том, какой объем памяти он имел.
Однако вы можете использовать jconsole для подключения к запущенному процессу Java, а затем использовать вкладку «Память», чтобы узнать размер кэша кода. Для полноты, шаги следующие (среда Linux VM, хотя я уверен, что другие среды аналогичны):
Опять же, это может занять некоторое время, прежде чем экран обновится, после чего вы должны увидеть что-то вроде:
Как видите, мой кеш кода занимает около 49 МБ. На данный момент у меня все еще было значение по умолчанию, которое, как сказано в документации (и @jeha), составляет 48 МБ. Безусловно, это отличная мотивация для меня увеличить настройку!
Бен.
1024 МБ по умолчанию, вероятно, переусердствовали, но 48 МБ по умолчанию, похоже, недостаточно ...
Хороший опыт обучения от команды разработчиков Indeed и проблемы, с которыми они столкнулись при переходе на jdk 8.
http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/
Вывод: Jdk 8 требует больше кеша кода, чем JDK 7
Размер кодового кеша по умолчанию для JRE 8 составляет около 250 МБ, что примерно в пять раз больше, чем 48 МБ по умолчанию для JRE 7. По нашему опыту, JRE 8 требует этого дополнительного кодового кеша. На данный момент мы переключили на JRE 8 около десяти сервисов, и все они используют примерно в четыре раза больше кодового кеша, чем раньше.
из https://blogs.oracle.com/poonam/entry/why_do_i_get_message :
Ниже приведены две известные проблемы в jdk7u4 +, связанные с очисткой CodeCache:
- Компилятор может не перезапуститься даже после того, как занятость CodeCache упадет почти до половины после аварийной очистки.
- Экстренная очистка может вызвать высокую загрузку ЦП потоками компилятора, что приведет к общему снижению производительности.
Эта проблема с производительностью, а также проблема того, что компилятор не включается снова, были решены в JDK8. Чтобы обойти это в JDK7u4 +, мы можем увеличить размер кэша кода, используя параметр ReservedCodeCacheSize, установив для него значение, превышающее размер скомпилированного кода, чтобы CodeCache никогда не заполнялся. Другое решение - отключить очистку кэша кода с помощью параметра -XX: -UseCodeCacheFlushing JVM.
Вышеупомянутые проблемы были исправлены в JDK8 и его обновлениях.
Так что эту информацию стоит упомянуть для систем, работающих на JDK 6 (с отключенным сбросом кода) и 7.