Я пытаюсь устранить очень длинные паузы при использовании сборщика CMS. Я использую Java 1.6.0u20 и планирую обновление до 1.7.0u71, но сейчас мы застряли на этой более старой версии.
Мне интересно, понимает ли кто-нибудь эти длинные «настоящие» паузы.
Машина является виртуальной машиной, но на хосте ESX всего 2 виртуальные машины, и они используют меньше, чем общее количество доступных ядер и оперативной памяти, поэтому подкачка не должна быть проблемой, но я не уверен на 100%. Любые советы, связанные с JVM на виртуальной машине, также будут оценены.
Увеличение кучи не помогает - мы начали с 1 ГБ на сборщике пропускной способности и перешли к 1,5, 2, 4, 5, 6, ... только вчера вечером я увеличил размер кучи до 10 ГБ. Проблема всегда остается с новыми размерами большего или меньшего размера и т. Д.
Вот сбой в параллельном режиме:
2014-11-13T09:36:12.805-0700: 34537.287: [GC 34537.288: [ParNew: 2836628K->2836628K(3058944K), 0.0000296 secs]34537.288: [CMS: 3532075K->1009314K(6989824K), 298.2601836 secs] 6368704K->1009314K(10048768K), [CMS Perm : 454750K->105512K(524288K)], 298.2603873 secs] [Times: user=5.89 sys=31.00, real=297.67 secs]
Total time for which application threads were stopped: 298.2647309 seconds
Вот провал продвижения:
2014-11-13T11:23:30.395-0700: 40974.985: [GC 40974.985: [ParNew (promotion failed)
Desired survivor size 223739904 bytes, new threshold 7 (max 7)
- age 1: 126097168 bytes, 126097168 total
: 3058944K->2972027K(3058944K), 1.6271403 secs]40976.612: [CMS: 6369748K->1735350K(6989824K), 26.6789774 secs] 9103364K->1735350K(10048768K), [CMS Perm : 129283K->105970K(524288K)], 28.3063205 secs] [Times: user=8.05 sys=2.08, real=28.38 secs]
Total time for which application threads were stopped: 28.3069287 seconds
Почему «реальное» время намного больше, чем время процессора / ядра?
[Times: user=5.89 sys=31.00, real=297.67 secs]
[Times: user=8.05 sys=2.08, real=28.38 secs]
