Оскільки Java 7 збирається використовувати новий збір сміття G1 за замовчуванням, чи зможе Java обробляти купу на порядок більший без передбачуваних "руйнівних" пауз GC? Хтось насправді впроваджував G1 у виробництво, який у вас був досвід?
Чесно кажучи, єдиний раз, коли я бачив справді довгі паузи GC, це дуже великі купи, набагато більше, ніж було б на робочій станції. Для роз’яснення мого питання; чи G1 відкриє шлюз до куп в сотні Гб? Туберкульоз?
Відповіді:
Здається, сенс G1 - мати менший час паузи, навіть до того моменту, коли він має можливість вказати максимальний час паузи.
Вивіз сміття - це не просто проста угода "Ей, вона повна, давайте перенесемо все відразу і почнемо спочатку" - це фантастично складна, багаторівнева, фонова різьбова система. Він може виконувати більшу частину свого обслуговування у фоновому режимі без взагалі пауз, а також використовує знання очікуваних шаблонів системи під час виконання - наприклад, припускаючи, що більшість об’єктів гине відразу після створення тощо.
Я б сказав, що час паузи GC буде продовжувати вдосконалюватися, а не погіршуватись, з наступними версіями.
РЕДАГУВАТИ:
під час повторного читання мені спало на думку, що я щодня використовую Java - Eclipse, Azureus та додатки, які розробляю, і вже давно, коли я побачив паузу. Не суттєва пауза, але я маю на увазі будь-яку паузу взагалі.
Я бачив паузи, коли я клацаю правою кнопкою миші на провіднику Windows або (зрідка), коли я підключаю певне обладнання USB, але з Java - взагалі жодного.
GC все ще є проблемою з кимось?
Я тестував це з важким додатком: 60-70 Гб, виділених до купи, з 20-50 Гб, що використовуються в будь-який час. З такими видами програм недопустимо стверджувати, що ваш пробіг може відрізнятися. Я використовую JDK 1.6_22 на Linux. Малі версії важливі - до приблизно 1.6_20 в G1 були помилки, які спричиняли випадкові NullPointerExceptions.
Я виявив, що дуже добре дотримуватися мети паузи, яку ви надаєте їй більшу частину часу. За замовчуванням видається пауза в 100 мс (0,1 секунди), і я казав їй зробити половину (-XX: MaxGCPauseMillis = 50). Однак, коли пам’яті стає дуже мало, вона панікує і робить повний збір сміття у світі. Завдяки 65 ГБ це займає від 30 секунд до 2 хвилин. (Кількість процесорів, ймовірно, не має різниці; можливо, вона обмежена швидкістю шини.)
Порівняно з CMS (яка не є стандартною GC сервера, але вона повинна бути для веб-серверів та інших додатків у режимі реального часу), типові паузи набагато передбачуваніші і можуть бути значно коротшими. Поки що я маю більше удачі з CMS для величезних пауз, але це може бути випадковим; Я бачу їх лише кілька разів кожні 24 години. Я не впевнений, який з них на даний момент буде більш доречним у моєму виробничому середовищі, але, мабуть, G1. Якщо Oracle продовжить налаштовувати його, я підозрюю, що G1 зрештою стане безперечним переможцем.
Якщо у вас немає проблем із існуючими збирачами сміття, зараз немає причин розглядати G1. Якщо у вас запущена програма з низькою затримкою, наприклад, програма з графічним інтерфейсом, G1, мабуть, є правильним вибором, оскільки MaxGCPauseMillis встановлений дуже низько. Якщо ви використовуєте пакетний режим, G1 вам нічого не купує.
Хоча я не тестував G1 у виробництві, я думав, що прокоментую, що GC вже є проблематичним для випадків без "величезних" куп. Зокрема, послуги з лише, скажімо, 2 або 4 концертами можуть сильно вплинути на GC. GC молодого покоління, як правило, не є проблематичним, оскільки вони закінчуються за однозначні мілісекунди (або щонайбільше двозначні). Але колекції старого покоління є набагато проблематичнішими, оскільки вони займають кілька секунд із розмірами старих поколінь 1 гіг або вище.
Тепер: теоретично CMS може там дуже допомогти, оскільки більшу частину своєї роботи вона може виконувати одночасно. Однак з часом траплятимуться випадки, коли він не може цього зробити, і йому доводиться відступати, щоб "зупинити світ". І коли це трапиться (скажімо, через 1 годину - не часто, але все-таки занадто часто), добре, тримайся своїх капелюхів. Це може зайняти хвилину і більше. Це особливо проблематично для служб, які намагаються обмежити максимальну затримку; замість того, щоб подати запит, скажімо, 25 мілісекунд, зараз потрібно десять секунд або більше. Щоб додати шкоди образі, клієнти часто таймають час запиту та повторюють спробу, що призводить до подальших проблем (інакше як "лайна").
Це одна область, де сподівалися, що G1 дуже допоможе. Я працював у великій компанії, яка пропонує хмарні послуги для зберігання та відправлення повідомлень; і ми не могли використовувати CMS, оскільки, хоча більшу частину часу він працював краще, ніж паралельні сорти, він мав ці розпади. Тож протягом години все було приємно; а потім речі потрапляють у вентилятор ... і оскільки сервіс базувався на кластерах, коли один вузол потрапляв у неприємності, інші, як правило, слідували (оскільки індуковані GC тайм-аути призводять до того, що інші вузли вважають, що вузол аварійно завершився, що призвело до повторних маршрутів).
Я не думаю, що GC є такою великою проблемою для програм, і, можливо, навіть некластеризовані послуги рідше зачіпаються. Але все більше і більше систем є кластеризованими (зокрема завдяки сховищам даних NoSQL) і розміри купи зростають. GC OldGen надзвичайно лінійно пов'язані з розміром купи (це означає, що подвоєння розміру купи більше, ніж подвоює час GC, припускаючи, що розмір поточного набору даних також подвоюється).
Технічний директор Azul Гіл Тене має хороший огляд проблем, пов’язаних зі збиранням сміття, та огляд різних рішень у своїй презентації « Розуміння збору сміття Java та те, що ви можете зробити з цим» , а в цій статті є додаткові подробиці: http: // www.infoq.com/articles/azul_gc_in_detail .
Колекціонер сміття Azul C4 у нашому Zing JVM одночасно паралельний і одночасний, і використовує один і той же механізм GC як для нового, так і для старих поколінь, працюючи одночасно та ущільнюючи в обох випадках. Найголовніше, що у C4 немає зупинки світу. Все ущільнення виконується одночасно з запущеним додатком. У нас є клієнти, що працюють дуже великими (сотні Гбайт), з гіршими випадками часу паузи GC <10 мсек, а залежно від програми часто менше, ніж 1-2 мсек.
Проблема CMS і G1 полягає в тому, що в якийсь момент пам'ять купи Java повинна бути ущільнена, і обидва ці збирачі сміття зупиняють світ / STW (тобто призупиняють програму) для виконання ущільнення. Отже, хоча CMS і G1 можуть виштовхувати паузи STW, вони їх не усувають. Однак C4 Azul повністю усуває паузи STW, і тому Zing має такі низькі паузи GC навіть для гігантських розмірів купи.
А щоб виправити заяву, зроблену в попередній відповіді, Zing не вимагає жодних змін в операційній системі. Він працює так само, як і будь-який інший JVM на незмінених дистрибутивах Linux.
Ми вже використовуємо G1GC, починаючи з майже двох років. Це чудово справляється з нашою критично важливою системою обробки транзакцій, і це виявилося чудовою підтримкою з високою пропускною здатністю, низькими паузами, паралельністю та оптимізованим важким управлінням пам'яттю.
Ми використовуємо такі налаштування JVM:
-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTimeОновлено
-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000Колектор G1 зменшує вплив повних колекцій. Якщо у вас є програма, де ви вже зменшили потребу в повних колекціях, колектор одночасної розгортки карт так само хороший, і, на мій досвід, коротший час незначного збору.
Здається, G1, починаючи з JDK7u4, нарешті офіційно підтримується, див. RN для JDK7u4 http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html .
Під час нашого тестування для великих JVM налаштована CMS все ще діє краще, ніж G1, але я думаю, вона буде рости краще.
Нещодавно мене переїхали з
Від CMS до G1GC з купою 4G і 8-ядерним процесором на серверах з JDK 1.7.45 .
(JDK 1.8.x G1GC є кращим за 1.7, але через деякі обмеження я повинен дотримуватися версії 1.7.45)
Я налаштував нижче ключові параметри і зберіг усі інші параметри до значень за замовчуванням.
-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n apart from -Xms and -XmxЯкщо ви хочете точно налаштувати ці параметри, перегляньте цю статтю оракула .
Основні спостереження:
Але все одно я радий, що час паузи Max GC менше, ніж у CMS. Я встановив максимальний час паузи GC 1,5 секунди, і це значення ще не перекреслено.
Пов’язане питання SE:
Система управління вмістом може призвести до повільної погіршення продуктивності, навіть якщо ви запускаєте її без накопичення об'єктів, що зберігаються. Це пов’язано з фрагментацією пам’яті, якої G1 нібито уникає.
Міф про G1, доступний лише з платною підтримкою, є саме цим, міфом. Sun і зараз Oracle пояснили це на сторінці JDK.
Нещодавно я переніс частину Twicsy на новий сервер із 128 ГБ оперативної пам'яті і вирішив використати 1.7. Я почав використовувати ті самі налаштування пам'яті, що і в 1.6 (у мене є кілька екземплярів, які виконують різні дії, десь від 500 МБ купи до 15 ГБ, а тепер новий із 40 ГБ), і це не вдалося взагалі. . Здається, 1.7 використовує більше купи, ніж 1.6, і я відчував багато проблем протягом перших кількох днів. На щастя, у мене було багато оперативної пам’яті, з якою я працював, і я нарізав оперативну пам’ять для більшості своїх процесів, але все одно мав деякі проблеми. Моїм звичайним MO було використовувати дуже малий мінімальний розмір купи 16 м, навіть з максимальною купою в кілька гігабайт, а потім увімкнути поступовий GC. Це зводило паузи до мінімуму. Це зараз не працює, і мені довелося збільшити мінімальний розмір приблизно до того, що я очікував використовувати в середньому в купі, і це вдалося дуже добре. У мене все ще ввімкнено поступовий GC, але я буду намагатися без нього. Зараз немає жодних пауз, і, здається, все працює дуже швидко. Отже, я думаю, що мораль історії - не чекайте, що ваші налаштування пам’яті будуть ідеально перекладені з 1,6 на 1,7.
G1 робить додаток набагато спритнішим: латентність програми зросте - додаток можна назвати "м'яким реальним часом". Це робиться шляхом заміни двох видів пробігів GC (малих другорядних та одного великого на Tenured Gen) на рівновеликі малі.
Детальніше див. Тут: http://geekroom.de/java/java-expertise-g1-fur-java-7/
Я працюю з Java для маленької та великої купи, і питання про GC та Full GC з’являється щодня, оскільки обмеження можуть бути більш суворими, ніж інші: в певному середовищі 0,1 секунди GC для сміття або Full GC вбивають просто fonctionnalité, і мають чітку конфігурацію та можливості, це важливо (CMS, iCMS, інші ... ціль тут, щоб мати якнайкращий час реакції при майже реальному часі обробки (тут обробка в реальному часі часто становить 25 мс) , тому, в основному, вітаються будь-які вдосконалення в ергономічності та евристиці GC!
Я використовую G1GC на Java 8, а також з Groovy (також Java 8), і я роблю різні види навантажень, і в цілому G1GC працює так:
Використання пам’яті дуже низьке, наприклад 100 Мб замість 500 Мб порівняно із налаштуваннями Java за замовчуванням
Час відгуку постійний і дуже низький
Продуктивність між налаштуваннями за замовчуванням і G1GC становить 20% уповільнення при використанні G1GC в гіршому випадку (без налаштування, однопоточна програма). Це мало що враховує хороший час відгуку та низьке використання пам'яті.
При запуску від багатопоточного Tomcat загальна продуктивність на 30% краща, а використання пам'яті значно нижче, а також час відгуку значно нижчий.
Отже, загалом, використовуючи дійсно різні робочі навантаження, G1GC є дуже хорошим колектором для Java 8 для багатопотокових програм, і навіть для однопотокових є деякі переваги.
Не рекомендується використовувати java8 w / G1GC для обчислення з плаваючою точкою з подібною точкою доступу JVM. Це небезпечно для цілісності та точності програми.
https://bugs.openjdk.java.net/browse/JDK-8148175
JDK-8165766
JDK-8186112