Не удалось избежать продвижения в Java CMS GC

У меня есть Java-приложение, использующее сборку мусора CMS, которое несколько раз в день страдает от полного GC «ParNew (продвижение не удалось)» (см. Пример ниже). Я понимаю, что сбой продвижения происходит, когда сборщик мусора не может найти достаточно (непрерывного) пространства в старом поколении для продвижения объекта из нового поколения. В этот момент он вынужден делать дорогостоящий полный сборщик мусора «Останови мир». Я хочу избежать таких событий.

Я прочитал несколько статей, которые предлагают возможные решения, но я хотел уточнить / консолидировать их здесь:

-Xmx: увеличить размер кучи, например. от 2G до 4G - простое решение, чтобы дать больше запаса в старом поколении - кажется, работает достаточно хорошо в моем опыте-XX: NewRatio: увеличить NewRatio, например. от 2 до 4, для того, чтобы увеличить старое поколение / уменьшить новое поколение - дать старому поколению больше места - похоже, пока что не имеет большого, если вообще есть, эффекта от моих экспериментов-XX: PromotedPadding: увеличить количество отступов, предусмотренных для предотвращения сбоев продвижения, однако я не могу найти никаких предложений о том, какие значения дать для этого параметра, кто-нибудь знает, что означает значение, что такое значение по умолчанию или какие значения пытаться?-XX: CMSInitiatingOccupancyFraction -XX: + UseCMSInitiatingOccupancyOnly: сделать запуск цикла CMS раньше, чтобы избежать недостатка места в старом поколении - я еще не пробовал это решение - какие значения было бы разумно попробовать? Что такое по умолчанию?Не выделяйте очень большие объекты в куче: очень большой объект может быть трудно продвинуть, так как он потребует большого непрерывного количества свободного пространства в старом поколении - это не относится к моему приложению, насколько я знаю

В случае, если это уместно, вот мои текущие параметры GC и пример журналов, предшествующих событию неудачного продвижения.

-Xmx4g -XX:+UseConcMarkSweepGC -XX:NewRatio=1

2014-12-19T09:38:34.304+0100: [GC (Allocation Failure) [ParNew: 1887488K->209664K(1887488K), 0.0685828 secs] 3115998K->1551788K(3984640K), 0.0690028 secs] [Times: user=0.50 sys=0.02, real=0.07 secs] 
2014-12-19T09:38:35.962+0100: [GC (Allocation Failure) [ParNew: 1887488K->208840K(1887488K), 0.0827565 secs] 3229612K->1687030K(3984640K), 0.0831611 secs] [Times: user=0.39 sys=0.03, real=0.08 secs] 
2014-12-19T09:38:39.975+0100: [GC (Allocation Failure) [ParNew: 1886664K->114108K(1887488K), 0.0442130 secs] 3364854K->1592298K(3984640K), 0.0446680 secs] [Times: user=0.31 sys=0.00, real=0.05 secs] 
2014-12-19T09:38:44.818+0100: [GC (Allocation Failure) [ParNew: 1791932K->167245K(1887488K), 0.0588917 secs] 3270122K->1645435K(3984640K), 0.0593308 secs] [Times: user=0.57 sys=0.00, real=0.06 secs] 
2014-12-19T09:38:49.239+0100: [GC (Allocation Failure) [ParNew (promotion failed): 1845069K->1819715K(1887488K), 0.4417916 secs][CMS: 1499941K->647982K(2097152K), 2.4203021 secs] 3323259K->647982K(3984640K), [Metaspace: 137778K->137778K(1177600K)], 2.8626552 secs] [Times: user=3.46 sys=0.01, real=2.86 secs] 

Ответы на вопрос(2)

Ваш ответ на вопрос