Java 7 вже деякий час виходить, але я не можу знайти хороших ресурсів щодо конфігурації збирачів сміття , зокрема нового колектора G1 .
Мої запитання:
Відповіді:
Збірник сміття G1 не є типовим у моїй установці Java, версія 1.7.0_01. Ви можете переконатися в цьому, скориставшись додатковими опціями командного рядка:
> java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -version
-XX:InitialHeapSize=132304640 -XX:MaxHeapSize=2116874240 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Heap
PSYoungGen total 37696K, used 1293K [0x00000007d5eb0000, 0x00000007d88c0000, 0x0000000800000000)
eden space 32320K, 4% used [0x00000007d5eb0000,0x00000007d5ff3408,0x00000007d7e40000)
from space 5376K, 0% used [0x00000007d8380000,0x00000007d8380000,0x00000007d88c0000)
to space 5376K, 0% used [0x00000007d7e40000,0x00000007d7e40000,0x00000007d8380000)
PSOldGen total 86144K, used 0K [0x0000000781c00000, 0x0000000787020000, 0x00000007d5eb0000)
object space 86144K, 0% used [0x0000000781c00000,0x0000000781c00000,0x0000000787020000)
PSPermGen total 21248K, used 2032K [0x000000077ca00000, 0x000000077dec0000, 0x0000000781c00000)
object space 21248K, 9% used [0x000000077ca00000,0x000000077cbfc288,0x000000077dec0000)
Вам не потрібно вмикати експериментальні опції, щоб більше вмикати колектор G1, однак:
> java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseG1GC -version
-XX:InitialHeapSize=132304640 -XX:MaxHeapSize=2116874240 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedOops -XX:+UseG1GC -XX:-UseLargePagesIndividualAllocation
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Heap
garbage-first heap total 130048K, used 0K [0x000000077ca00000, 0x0000000784900000, 0x00000007fae00000)
region size 1024K, 1 young (1024K), 0 survivors (0K)
compacting perm gen total 20480K, used 2032K [0x00000007fae00000, 0x00000007fc200000, 0x0000000800000000)
the space 20480K, 9% used [0x00000007fae00000, 0x00000007faffc288, 0x00000007faffc400, 0x00000007fc200000)
No shared spaces configured.
Я не знаю, де ви можете знайти якісну документацію.
-XX:+UseParallelGC.
Oracle нарешті зробив G1 офіційним в Java 7 U4: http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html
Опис: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/G1.html
Параметри командного рядка: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#G1Options
Тим не менше, я не думаю, що це колектор за замовчуванням у Java 7. Для серверів типовим є Parallel Collector як у Java 6.
Так, G1 - це новий стандартний збирач сміття в Java 1.7 JVM.
Тут ви знайдете багато інформації про те, як користуватися та налаштовувати новий збирач сміття:
Використання G1 G1 досі вважається експериментальним і може бути увімкнено з наступними двома параметрами:
-XX: + UnlockExperimentalVMOptions -XX: + Використовуйте G1GC
Щоб встановити мету часу паузи в GC, використовуйте такий параметр:
-XX: MaxGCPauseMillis = 50 (для цільового часу паузи 50 мс)
Для G1 можна вказати інтервал часу, протягом якого пауза GC не повинна тривати довше часу, вказаного вище:
-XX: GCPauseIntervalMillis = 200 (для цільового інтервалу паузи 200 мс)
Зверніть увагу, що два вищезазначені варіанти представляють цілі, а не обіцянки чи гарантії. Вони можуть добре працювати в одних ситуаціях, але не в інших, і GC не завжди може їм підкорятися.
Крім того, розмір молодого покоління можна чітко вказати, щоб вплинути на час паузи евакуації:
-XX: + G1YoungGenSize = 512 м (для молодого покоління 512 мегабайт)
G1 також використовує еквівалент просторів, що вижили, які, природно, являють собою набір (потенційно не суміжних) регіонів. Їх розмір можна вказати за допомогою звичайних параметрів (наприклад, -XX: SurvivorRatio = 6).
Нарешті, щоб запустити G1 у повному обсязі, спробуйте встановити ці два параметри, які в даний час вимкнені за замовчуванням, оскільки вони можуть виявити рідкісні умови перегонів:
-XX: + G1ParallelRSetUpdatingEnabled -XX: + G1ParallelRSetScanningEnabled
Ще одне, на що слід звернути увагу, це те, що G1 дуже багатослівний порівняно з іншими GC HotSpot, коли встановлено -XX: + PrintGCDetails. Це пов’язано з тим, що він друкує синхронізацію на GC-потоці та іншу інформацію, яка дуже корисна для профілювання та пошуку несправностей. Якщо ви хочете отримати більш стислий журнал GC, будь ласка, перейдіть на використання -verbosegc (хоча рекомендується отримати більш детальний журнал GC).
Я також знайшов цю статтю дуже корисною для розуміння суті G1.
Навіть більше інформації тут .
1. Чи є G1 колектором за замовчуванням у Java 7 (...)
Правило на цій сторінці Java 5 все ще застосовується в Java 7 (і AFAIK, Java 8):
На машинах серверного класу, на яких запущена серверна віртуальна машина, збирач сміття (GC) змінився з попереднього послідовного збирача (-XX: + UseSerialGC) на паралельний колектор (-XX: + UseParallelGC).
Але також враховуйте:
-clientВМ, тому завжди є "класом сервера"Наприклад, якщо у Windows x64 ви запускаєте ...
1. (...) як активувати G1?
Що стосується Java 7, просто -XX:+UseG1GC. Можливо, також цікаво, коли ви хочете:
Програми, що працюють сьогодні із CMS або збирачем сміття ParallelOld, було б корисно перейти на G1, якщо програма має одну або кілька з наступних ознак.
- Понад 50% купи Java зайнято реальними даними.
- Швидкість розподілу об'єктів або просування по службі значно варіюється.
- Небажані довгі паузи для збору або ущільнення сміття (довше 0,5-1 секунди)
2. Які необов’язкові налаштування має g1 у Java7?
Я сам не використовував G1, але я вважаю, що він дотримується тих самих основних "пропускних / ергономічних" прапорів, що використовуються для настройки інших паралельних колекторів. На моєму досвіді роботи з Parallel GC, -XX:GCTimeRatioвін став ключовим у забезпеченні очікуваного компромісу зі швидкістю пам'яті. YMMV.
Параметри G1-специфічні перераховані тут
3. Чи були зміни в (...) cms або паралельному колекторі в Java 7?
Не знаю, але ...
G1 заплановано як довгострокову заміну одночасного колектора марк-розгортки (CMS)
4. Де я можу знайти хорошу документацію щодо збору сміття в Java 7?
Це може бути біль знайти, чи не так? Можливо, найкраща сторінка "концентратора", яку я знайшов, - це ця:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html
Потрібне глибоке читання, але варто витратити час, якщо вам потрібно виконати певну настройку. Особливо проникливим є: Ергономіка збирача сміття
- Чи є G1 колектором за замовчуванням у Java 7, і як ні, як активувати G1?
G1 не є колектором за замовчуванням у Java 7. -XX:+UseG1GCувімкне G1GC
- Які додаткові налаштування має g1 у Java7?
Тут багато. Подивіться цю статтю оракула, щоб отримати повну інформацію.
G1 GC - це адаптивний збирач сміття із замовчуванням, які дозволяють йому працювати ефективно без змін.
З цієї причини налаштуйте критичні параметри
-XX:MaxGCPauseMillis
-XX:G1HeapRegionSize
-XX:ParallelGCThreads
-XX:ConcGCThreads
а всі інші параметри залиште за значенням за замовчуванням .
Ось список важливих параметрів та значення за замовчуванням. Цей список стосується останньої версії Java HotSpot VM, збірка 24. Ви можете адаптувати та налаштувати параметри G1 GC у командному рядку JVM.
Важливі значення за замовчуванням:
-XX:G1HeapRegionSize=n
Встановлює розмір області G1. Значення буде дорівнювати двом і може коливатися від 1 МБ до 32 МБ. Мета полягає в тому, щоб мати близько 2048 регіонів на основі мінімального розміру купи Java.
-XX:MaxGCPauseMillis=200
Встановлює цільове значення для бажаного максимального часу паузи. Значення за замовчуванням - 200 мілісекунд. Вказане значення не відповідає вашому розміру купи.
-XX:G1NewSizePercent=5
Встановлює відсоток купи, який слід використовувати як мінімальний для розміру молодого покоління. Значення за замовчуванням - 5 відсотків вашої купи Java.
-XX:G1MaxNewSizePercent=60
Встановлює відсоток розміру купи, який слід використовувати як максимальний для розміру молодого покоління. Значення за замовчуванням - 60 відсотків вашої купи Java.
-XX:ParallelGCThreads=n
Встановлює значення робочих потоків STW. Встановлює значення n на кількість логічних процесорів. Значення n таке саме, як кількість логічних процесорів до значення 8.
Якщо існує більше восьми логічних процесорів, встановлює значення n приблизно до 5/8 логічних процесорів. Це працює в більшості випадків, за винятком більших систем SPARC, де значення n може становити приблизно 5/16 логічних процесорів.
-XX:ConcGCThreads=n
Встановлює кількість паралельних ниток розмітки. Встановлює n приблизно до 1/4 кількості паралельних потоків збору сміття (ParallelGCThreads).
-XX:InitiatingHeapOccupancyPercent=45
Встановлює поріг заповнення кучі Java, який запускає цикл маркування. Заповнення за замовчуванням становить 45 відсотків всієї кучі Java.
-XX:G1MixedGCLiveThresholdPercent=65
Встановлює поріг заповнюваності для старого регіону, який повинен бути включений у змішаний цикл вивезення сміття. Зайнятість за замовчуванням становить 65 відсотків
-XX:G1HeapWastePercent=10
Встановлює відсоток купи, яку ви готові витратити. Java HotSpot VM не ініціює змішаний цикл вивезення сміття, коли відсотковий відсоток менше, ніж відсоток відвалів купи
-XX:G1MixedGCCountTarget=8
Встановлює цільову кількість змішаних зборів сміття після циклу розмітки для збору старих регіонів із щонайбільше G1MixedGCLIveThresholdPercent реальними даними. За замовчуванням - 8 змішаних сміттєвих колекцій
-XX:G1OldCSetRegionThresholdPercent=10
Встановлює верхню межу кількості старих регіонів, що збираються під час змішаного циклу збору сміття. За замовчуванням 10 відсотків купи Java
-XX:G1ReservePercent=10
Встановлює відсоток резервної пам'яті, щоб вона залишалася вільною, щоб зменшити ризик переповнення простору. За замовчуванням 10 відсотків. Коли ви збільшуєте або зменшуєте відсоток, переконайтеся, що загальну купу Java налаштовано на однакову величину.
Ви переконфігурували багато параметрів G1GC, які не потрібні, якщо ви дотримуєтесь вищезазначеної сторінки документації. Будь ласка, перевірте наведені вище рекомендації, особливо щодо ParallelGCThreads та ConcGCThreads , які мають базуватися на ядрах вашого процесора. Видалити повторну конфігурацію непотрібних параметрів.
Рекомендації від oracle:
Під час оцінки та точної настройки G1 GC пам’ятайте про наступні рекомендації:
Розмір молодого покоління : уникайте явного встановлення розміру молодого покоління за допомогою -Xmnпараметра чи будь-якого іншого суміжного параметра, наприклад -XX:NewRatio. Визначення розміру молодого покоління замінює цільову мету часу паузи .
Пауза Цілі в часі: Коли ви оцінюєте або налаштовуєте будь-який збір сміття, завжди є затримка проти компромісу між пропускною спроможністю. G1 GC - це додатковий збирач сміття з рівномірними паузами, але також більшими накладними витратами на потоки додатків. Метою пропускної здатності для G1 GC є 90 відсотків часу нанесення та 10 відсотків часу збору сміття .
- Чи були внесені зміни до інших колекторів, таких як cms або паралельний колектор в Java 7?
У Java 7. є деякі зміни. Погляньте на цю статтю
- Де я можу знайти хорошу документацію щодо збору сміття в Java 7?
Зверніться до сторінки документації oracle про gc та відповідне питання про SE:
Жоден G1 не є типовим збирачем сміття в jdk 1.7.0_02. За замовчуванням збирач сміття залежить від класу машини. Якщо машина має клас сервера, то за замовчуванням збирач сміття - це Пропускна здатність. Якщо машина класу клієнта, то за замовчуванням збирач сміття - це послідовний збирач.
Документація, доступна за адресою http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html (посилання, надане Войтеком), здається, є єдиним офіційним посиланням з інформацією, здається застарілим, оскільки деякі згадані там прапори були доступні лише в тестових збірках, вони більше не існують у виробничих випусках. Хтось із Oracle повинен надати оновлену документацію щодо G1 GC.
За замовчуванням ви насправді не хочете використовувати колектор G1, оскільки він насправді не кращий за інші. Це добре лише для спеціальних цілей.
При низькій затримці додаток значно вищий, ніж CMS, оскільки має трохи коротший час та більш передбачуваний час паузи. В обмін пропускна здатність набагато гірша, ніж CMS в обміні.
Тож добре, якщо затримка важлива, але пропускна здатність зовсім не важлива. Якщо обидва важливі, то залишайтеся з CMS.