У меня есть приложение весенней загрузки java, которое, как предполагается, долго работает и требует времени отклика <50 мс. Обычно мы можем это обработать, но когда старый ген приблизится к заполнению, включается CMS, и наше SLA времени отклика нарушается. Есть ли какая-либо стратегия, которую я могу использовать, чтобы гарантировать, что полный GC никогда не заработает. </p>
Мой сервер интенсивно использует IO, мы не храним ничего в памяти, но много параллельных операций ввода-вывода (30 тыс. Об / мин), каждая из которых выполняет ответную реакцию ввода-выводаоколо 3-4 МБ данных. Из журналов я наблюдал, что второстепенный сборщик мусора запускался почти 3-4 раза в секунду, второстепенный сборщик мусора запускался очень часто из-за небольшого пространства Эдема и выжившего (пространство Эдема составляло 600 МБ, а пространство выжившего - 75 МБ). Из-за очень частых сборщиков мусора объекты могут пережить порог второстепенных сборщиков мусора (15) и получить старое поколение. Поэтому я увеличил пространство своего молодого поколения, сделав -XX:NewRatio=1
.
Проблема по-прежнему сохраняется. Я вижу журнал ошибок распределения (как показано ниже) 3-4 раза в секунду
[GC (Allocation Failure) 56455.997: [ParNew: 10705358K->222390K(11796480K), 0.0467254 secs] 13148872K->2667031K(24903680K), 0.0468292 secs] [Times: user=0.34 sys=0.00, real=0.05 secs]
Используя новую реликвию, я контролировал память,young gen постоянен, в то время как old gen продолжает расти, ниже приведен снимок.
![enter image description here](https://i.stack.imgur.com/3ognX.png)
Хорошая стратегия распределения кучи для моего приложения, я думаю, будет гдемолодой ген постоянно наполняется и опорожняется, в то время как старый ген почти не используется, поскольку у нас почти нет долгоживущих предметов. Пожалуйста, предложите, как достичь вышеизложенного или какие-либо лучшие стратегии, которые вы можете иметь в виду