В тази статия, аз не бих искал да се съсредоточи върху принципа на работа на боклукчията - това е добре и ясно е описано тук: habrahabr.ru/post/112676/. Искате повече отидете на практическите основи и количествени характеристики за конфигуриране на събиране на боклука в JVM - и да се опитаме да разберем как тя може да бъде характеристики effektivnym.Kolichestvennye GCRassmotrim оценка на ефективността на следните параметри: Скорост Мярка, която определя способността на приложението да работи в върхово натоварване, независимо от паузите по време на монтаж и необходимия размер памет GC отговор мярката време, което определя способността на приложението, за да се справят с колебания в броя на спиранията и работа с помощта на GC размер emoy памет размер на паметта, която се изисква за ефективно GC-общо, тези характеристики са компрометирани и подобрени един от тях води до останалите разходи. За повечето приложения, и трите важни характеристики, но често един или два са по-важни за прилагане - това ще бъде отправна точка, за да се създаде.
Основни принципи на GC тунинг разгледа три основни фундаментални разбиране на правилата за настройки GC:
внос java.util.ArrayList; внос java.util.List; внос java.util.concurrent.ExecutorService; java.util.concurrent.Executors внос;
обществен MemoryConsumer клас изпълнява Изпълнима
частен статично окончателно вътр OBJECT_SIZE = 1024 × 1024; частен статичен краен Int OBJECTS_NUMBER = 8; частен статичен краен Int ADD_PROCESS_TIME = 1000; частни статични крайните INT NUMBER_OF_REQUEST_THREADS = 50; частен статично окончателно дълго EXPERIMENT_TIME = 30000; частен статично булев спирка летлив = неверни;
публично статично невалидни основни (String [] опцията) хвърля InterruptedException
започнете (); Thread.sleep (EXPERIMENT_TIME); спре ();>
частен статично невалидни старт () Java -XX: + PrintGCTimeStamps -XX: + PrintGCDetails -verbose: GC -Xloggc: gc.log ru.skuptsov.MemoryConsumer забавяне и сума дере gc.log: 0.167: [Пълен GC [PSYoungGen: 21792K → 13324K (152896K)] [PSOldGen: 341095K → 349363K (349568K)] 362888K → 362687K (502464K) [PSPermGen: 2581K → 2581K (21248K)], 0.0079385 сек] [Times: потребител = 0.01 сис = 0.00, реални = 0.01 сек] Където реални = 0.01 сек - действителното време, прекарано на sborku.A полезност може да се използва VisualVM, плъгин инсталиран VisualGC, което ясно може да се види разпределението на паметта в различни области на GC (Eden, Survivor1, Survivor2, старо) и да видите статистически данни за началото и продължителността на събиране на боклук. Определяне на необходимия размер на паметта в началото, трябва да стартирате приложението, с възможно най-голям обем памет, отколкото е действително необходима молба. Ако не знаехме първоначално колко ще отнеме нашата молба в паметта - можете да стартирате приложението, без да се посочва -Xmx и -Xms и HotSpot VM ще изберете размера на паметта. Ако в началото на прилагането ние ще се OutOfMemory (Java купчина пространство или PermGen пространство), тогава можем да итеративно се увеличи наличната размерът на паметта (-Xmx или -XX: PermSize), докато грешката не е uydut.Sleduyuschim стъпка е да се изчисли размерът на дълготрайните живо данни - размера на старите и постоянни области на купчината след фазата на пълното събиране на боклука. Този размер - приблизителния размер на паметта, необходима за функционирането на заявлението, за да я получи, можете да видите размера на площта, след серия от цялото събрание. Обикновено размерът на паметта, необходима за прилагането -Xms и -Xmx 3-4 пъти повече от сумата, на живи данни. Така че, за да дневника, по-горе - стара стойност на терена след фаза на пълно събиране на боклука - 349363K. Тогава предложената стойност -Xmx и -Xms 1400 MB. -XX: PermSize и -XX: MaxPermSize - 1.5 пъти повече от PermGenSize След фазата на пълното събиране на боклука - 13324K 20 MB. Размерът на младото поколение отнема еднакъв размер 1-1,5 обем на живо данни 525 MB. Тогава ние се низ JVM тичам със следните параметри: Java -Xms1400m -Xmx1400m -Xmn525m -XX: PermSize = 20м ru.skuptsov.MemoryConsumer В VisualVm получи следната картина:
Като цяло е постигнат 54 монтаж за 30 секунди от експеримента - 31 малки и 23 пълен - с общо време за спиране 3,227c. Този размер на закъснение не може да отговори на необходимите изисквания - ще видим дали можем да подобрим ситуацията, без да променя кода на приложението.
Създаване допустимото време за отговор следните параметри трябва да се измерват и се вземат предвид при определяне на времето за реакция: Измерване на малки събиране на боклука продължителност Честота на измерване боклук малък монтаж измерване на дължината на най-лошия случай на пълно събиране на боклука честота Измерване на най-лошия случай пълни корекции за събиране на боклук до времето на млади и стари поколение, необходими за изпълнение събиране фаза малък боклук зависи от броя на обектите в младото поколение, по-малкия му размер - по-ниската продължителност, но това увеличава порции че поради област често започва да се запълнят. Опитайте се да намалите времето на всяка малка събрание чрез намаляване на размера на младото поколение, като същевременно се запази размера на старата генерация. Грубо може да се изчисли, че всяка секунда ние трябва да се изчисти в младото поколение 50potokov 8obektov * * 1MB
400Mbps. Стартирайте със следните параметри: Java -Xms1275m -Xmx1275m -Xmn400m -XX: PermSize = 20 m ru.skuptsov.MemoryConsumer В VisualVm получи следната картина:
Общото време на боклука, ние не бяхме в състояние да засегне малък строителство - 1,533s - повишена честота на малки възли, но общото време се е влошило - 3661 се дължи на факта, че повишена честота на старата генерация и повишената честота на повикване пълна колекция боклук запълни. За да се преодолее това - се опита да увеличи размера на старото поколение - JVM план със следните параметри:
Java -Xms1400m -Xmx1400m -Xmn400m -XX: PermSize = 20 м ru.skuptsov.MemoryConsumer
Общо пауза вече е подобрена и е в размер на 2637, и се изисква от общата стойност за прилагане на паметта в същото време намалява - по този начин итеративно, можете да се намери правилният баланс между старото и младото поколение за разпределение на времето на живот на обектите в дадено приложение.
Когато времето, все още не е удовлетворен от нас - можете да отидете на колектора едновременното боклук, включително -XX на опция: + UseConcMarkSweepGC - алгоритъм, който ще се опита да извърши работа по същество относно маркировката обекти за заличаване в отделен поток тече паралелни приложения.
Създаване Едновременното боклучар ConcMarkSweep GC изисква по-внимателни настройки - една от основните цели е да се намали стоп-света спира при липса на достатъчно пространство в старата генерация на позициите на обекти - като Тази фаза отнема средно по-дълго от фазата на пълното събиране на боклука, когато пропускателна GC. В резултат на това - може да увеличи продължителността на най-лошия случай събирането на боклука, е необходимо да се избегнат честите преливания старата генерация. Като правило, - по време на прехода към ConcMarkSweep GC препоръчва да се увеличи размера на възраст поколение 20-30% - JVM план със следните параметри: Java -Xms1680m -Xmx1680m -Xmn400m -XX: + UseConcMarkSweepGC -XX: PermSize = 20m ru.skuptsov.MemoryConsumer
Общо почивка спадна до 1,923 секунди.
Приспособяване на размера на оцелял под под диаграмата можете да видите размера на паметта на разпределението на приложения в зависимост от броя на прехода между етапи на Eden, Survivor1 и Survivor2 преди да стигнем до Стария поколение. Факт е, че един от начините да се намали броят на залято в старата генерация ConcMarkSweep GC - предотвратяване на директното движение на обекти от младото поколение директно в старата - заобикаляйки оцелял oblasti.Dlya проследяване на разпространението на предмети на сцената, можете да започнете с JVM с опция -XX: + PrintTenuringDistribution. В gc.log можем да наблюдаваме:
Желана оцелял размер 20971520 байта, нов праг 1 (макс 4) - възрастови 1: 40900584 байта, 40,900,584 общите габарити наследствените обекти - 40900584, CMS използва по подразбиране 50% заетост бариера област преживяло. По този начин ние се получи размера на региона
80 MB. Когато бъде стартиран, тя се JVM параметър -XX: SurvivorRatio, която се определя от формула: наследствена размера пространство = -Xmn / (- XX: SurvivorRatio = + 2) за да се получи
Java -Xms1680m -Xmx1680m -Xmn400m -XX: SurvivorRatio = 3 -XX: + UseConcMarkSweepGC -XX: PermSize = 20 метра ru.skuptsov.MemoryConsumer Желаещи да напусне Eden пространство с размерите на една и съща - да стигнем: Java -Xms1760m -Xmx1760m -Xmn480m -XX: SurvivorRatio = 5 -XX: + UseConcMarkSweepGC -XX: PermSize = 20m ru.skuptsov.MemoryConsumer
Разпределението е по-добре, но общото време не се е променило много, поради спецификата на приложението, факт е, че след чести малки колекции боклук размера на оцелелите обекти е винаги по-голям от размера на разположение на зоните оцелял, така че в този случай можем да дарят правилното разпределение в полза на размер Eden пространство:
Java -Xms1760m -Xmx1760m -Xmn480m -XX: SurvivorRatio = 100 -XX: + UseConcMarkSweepGC -XX: PermSize = двайсетм ru.skuptsov.MemoryConsumer
Резултат Като резултат, ние бяхме в състояние да се намали общия размер на паузата с 3227 до 1481 с 30 да експериментирате малко, докато се повишава общото потребление на паметта. Много или малко - зависи от специфичните особености, по-специално, като се има предвид тенденцията за намаляване на разходите за физическа памет и на принципа на максимално използване на памет - все пак е важно да се намери баланс между различните области на GC и процесът е по-творчески отколкото научна.
Свързани статии