Java 8 young gc стоит больше 1 с, как сократить время работы нового поколения gc

Question

Описание вопроса

Наше Java-приложение работает в Docker, использующем Java 8 и 6C, 8g.

Алгоритм сбора мусора использует parNew + CMS, но почти никогдаtouch off olg gen gc.

Framework: Spring + mybatis + dubbo + RocketMQ.

Вот параметры JVM:

-server -Xmx5g -Xms5g -Xmn1g -XX: MetaspaceSize = 512m -XX: MaxMetaspaceSize = 512m -Xss256k -XX: SurvivorRatio = 8 -XX: + PrintGCDetails -Xloggc: /opt/apps/logs/gc.log -XX: + PrintGCDateStamps -X::XX: + PrintSafepointStatistics -XX: PrintSafepointStatisticsCount = 1 -XX: + PrintReferenceGC -XX: + UnlockDiagnosticVMOptions -XX: -DisplayVMOutput -XX: + LogVMOutput -XX: LogFile = / opt / apps / logs / безопасное использование.-XX: + UseConcMarkSweepGC -XX: CMSInitiatingOccupancyFraction = 70 -XX: + CMSParallelRemarkEnabled -XX: + UseCMSCompactAtFullCollection -XX: + UseFastAccessorMethods -XX: + UseCastInccessatingOmp_OxOmpOupOccancy: OXOpOpOupOccancy/ apps / logs

Я потратил две недели на эту проблему, но не могу выяснить, с чем это связано.Во-первых, я открываю журнал GC и журнал безопасных точек, сомневаясь, что причиной может быть безопасная точка.Но я обнаружил, что время вращения + время блокировки было очень коротким.Только когда произошел молодой gc, время vmop почти совпадает с временем остановки молодого gc.

А затем я проверяю коллекцию FinalRefence и добавляю PrintReferenceGC.Это тоже было очень коротко.

Вот журнал gc

2019-09-20T03: 03: 37.816 + 0800: 23271.179: [GC (Ошибка распределения) 2019-09-20T03: 03: 37,818 + 0800: 23271,180: [ParNew2019-09-20T03: 03: 39,394 + 0800: 23272,756: [SoftReference, 0 ссылок, 0,0000626 секунд] 2019-09-20T03: 03: 39.394 + 0800: 23272,756: [WeakReference, 92 ссылки, 0,0000400 секунд] 2019-09-20T03: 03: 39,394 + 0800: 23272,756: [FinalReference, 55 ссылок, 0,0001404 секунды] 2019-09-20T03: 03: 39,394 + 0800: 23272,756: [PhantomReference, 0 ссылок,0 ссылок, 0,0000298 с] 2019-09-20T03: 03: 39,394 + 0800: 23272,756: [Слабая ссылка JNI, 0,0000552 с]: 845514K-> 6643 К (943744K), 1,5767273 с] 1160791 К-> 322039 К (51380488 с), 1,57] [Время: пользователь = 5,21 сис = 0,17, реальное = 1,57 с] 2019-09-20T03: 03: 39.396 + 0800: 23272,758: общее время, в течение которого потоки приложения были остановлены: 1,5826799 секунд, остановка потоков заняла: 0,0005805 секунд

Вот журнал безопасных точек

vmop [threads: total initial_running wait_to_block] [время: очистка синхронизации спинового блока vmop] page_trap_count 23271.176: GenCollectForAllocation [1699 0 2] [0 0 0 2 1578] 0

Answer 1

Проблема была решена.Мы обнаружили, что JVM в докере получил неправильный номер ядра процессора.Номер, который был из чистого металла, но не из конфигурации докера.Я добавил -XX: ParallelGCThreads = 6, чтобы контролировать номер потока parNew gc.Время GC сократилось до 50 мс, и оно было стабильным.

Answer 2

Как видно из оставшейся кучи, занятой после молодой коллекции, размер живого набора (который включает в себя молодые и старые объекты) вашего приложения составляет <300 МБ.Ваш общий размер кучи составляет 5 ГБ, поэтому имеется много передышек. </p>

А поскольку здесь есть передышка и время молодой паузы, вы можете попытаться сжать молодое поколение, что может немного увеличить скорость владения,но коллектор старого поколения CMS должен быть в состоянии справиться с этим.

Из предоставленных вами журналов GC: * ​​1005 *

2019-09-20T07:56:55.968+0800: 40869.330: [GC (Allocation Failure) 2019-09-20T07:56:55.969+0800: 40869.331: [ParNew2019-09-20T07:56:56.006+0800: 40869.368: [SoftReference, 0 refs, 0.0000588 secs]2019-09-20T07:56:56.006+0800: 40869.368: [WeakReference, 114 refs, 0.0000369 secs]2019-09-20T07:56:56.006+0800: 40869.368: [FinalReference, 22 refs, 0.0000404 secs]2019-09-20T07:56:56.006+0800: 40869.368: [PhantomReference, 0 refs, 0 refs, 0.0000298 secs]2019-09-20T07:56:56.006+0800: 40869.368: [JNI Weak Reference, 0.0000626 secs]: 842095K->3179K(943744K), 0.0378130 secs] 1170641K->331912K(5138048K), 0.0394628 secs] [Times: user=0.70 sys=0.42, real=0.04 secs] 
2019-09-20T07:58:44.545+0800: 40977.907: [GC (Allocation Failure) 2019-09-20T07:58:44.545+0800: 40977.908: [ParNew2019-09-20T07:58:45.798+0800: 40979.160: [SoftReference, 0 refs, 0.0000641 secs]2019-09-20T07:58:45.798+0800: 40979.160: [WeakReference, 116 refs, 0.0000436 secs]2019-09-20T07:58:45.798+0800: 40979.160: [FinalReference, 14 refs, 0.0000217 secs]2019-09-20T07:58:45.798+0800: 40979.160: [PhantomReference, 0 refs, 0 refs, 0.0000293 secs]2019-09-20T07:58:45.798+0800: 40979.160: [JNI Weak Reference, 0.0000510 secs]: 842091K->3159K(943744K), 1.2526309 secs] 1170824K->331976K(5138048K), 1.2541209 secs] [Times: user=6.73 sys=0.66, real=1.26 secs] 

Эти две коллекции выполняют одинаковый объем работы, но для этого требуется10x циклов процессора и 30x время простояОбычно это указывает на причину вне JVM, то есть на другие процессы или (как предположил Алексей) виртуальные машины-побратимы, борющиеся за ресурсы пропускной способности ЦП или памяти.Может также возникнуть проблема с тепловым регулированием ЦП, но это не так часто встречается в серверных средах.