Как вы определяете CMSInitiatingOccupancyFraction для больших Java-приложений?

Question

Мы используем базу данных (Apache Geode), написанную на Java.Наши серверы имеют 64 г оперативной памяти, поэтому мы установили для кучи Java (Xms и Xmx) около 62 г оперативной памяти.

Большинство рекомендаций Java, которые я видел для подобных ситуаций, это использовать сборщик мусора CMS и установить CMSInitiatingOccupancyFraction где-то около 68% (давать или брать немного, но не очень).

Но мой вопрос таков: почему мы не можем установить сборку мусора на 95% вместо 68%?Может показаться расточительным запускать Java таким образом, что вы никогда не сможете использовать более 68% своей кучи, не вызывая безостановочного сбора мусора.

Это нас беспокоит, потому что мы находимся на этапе, когда наша база данныхбезостановочная сборка мусора, и трудно оправдать больший объем оперативной памяти, когда на самом деле JVM имеет около 18 гигабайт бесплатно.:)

Заранее спасибо за любые советы.

Answer 1

Я думаю, что ответы в комментариях, плюс некоторые вещи, которые мне удалось выяснить, в значительной степени отвечают на мой вопрос.

Кажется, одной из проблем является фрагментация.У вас может быть 20% свободной кучи (используется 80%), и все же ваша куча может быть сильно фрагментирована там, где трудно найти большие непрерывные блоки, необходимые для работы.Если вы начнете использовать GC раньше, например, на 70%, вы будете держать фрагментацию под контролем, исправляя неиспользуемые объекты и создавая большие дыры для новых объектов.

Для некомпактных GC, таких как CMS, нет 100% гарантии, что вы никогда не станете слишком фрагментированными для выделения блока памяти, но если вы собираете рано и часто, вы можете сделать это так же редко, каквозможно.