Какво трябва да се провери в gc.logs

Знам много неща за това какво трябва да се възприема от gc.logs като

  • трябва да проверите колко често се изпълнява "Full GC", ако работи често, това е знак за проблем
  • трябва също така да проверите колко памет "Full GC" може да възстанови, докато завърши, ако не е много, това отново е признак на проблем, тъй като би принудило "Full GC" да стартира отново
  • трябва да прегледате отново пространството на купчината, разпределено за java процес, ако "Пълният GC" се изпълнява често.

Това са някои точки, върху които работя, ще ми е интересно да знам какво друго трябва да се внимава, когато гледам gc регистрационните файлове.

FYI, вече прегледах следните теми....


java performance jvm garbage-collection
person Rupesh    schedule 07.12.2014    source източник

Отговори (1)


arrow_upward
2
arrow_downward

Първо трябва да знаете какво лошо може да направи GC на вашата програма. В зависимост от вида на колекторите, които използвате за тенуурирано и старо поколение, съдържанието на регистрационните файлове на GC може да варира. Но като цяло основният извод, който трябва да извлечем от gc регистрационните файлове, е концентриран най-вече до следното:

  • Колко време отнемат малките колекции?
  • Колко време отнемат основните колекции?
  • Каква е честотата на незначителните колекции?
  • Каква е честотата на основните колекции?
  • Колко възстановява малка колекция?
  • Колко възстановява голяма колекция?
  • Комбинации от горните

Повечето програми имат много чести незначителни колекции, които изискват около 90-95% от купчината и предават останалото на пространствата на Survivor. Следващите колекции изчистват отново оцелелите с около 80% и по същество само 2% до 4% от вашата действителна незначителна колекция стига до старо поколение и тези цикли продължават, без значение кой Collector използвате.

Сега проблемните области са, когато имате стотици малки по размер незначителни колекции на заявка за приложение или нишка и когато се сумират, те правят значително време най-вече в двуцифрени секунди. Тъй като в съвременните колекционери незначителното преминаване и почистване не спират световните случаи, така че нещо това е поносимо. При Old gen проблемите идват, когато колекционерите работят, но не възстановяват нищо значително. например: обикновено колекторът работи, когато старият генератор е пълен на около 80-85%. Това може да е спиране на световния епизод, тъй като новите данни не могат да бъдат записани в купчина, освен ако купчината има повече място, което вероятно е случаят тук. Така нишките на приложението се поставят на пауза, за да позволят на нишките на GC да почистят първо пространството. но след като колекторът приключи, коефициентът на запълване на купчината не намалява толкова, колкото би трябвало. Доброто оразмеряване трябва да намали купчината ви с повече от 40% наведнъж. Ако това не стане, това означава, че имате нужда от повече купчина, за да запазите вашите дълготрайни обекти.

Така че по същество GC анализът не е нещо „направи го въз основа на набор от предварително дефинирани стъпки“. Това е по-скоро hti и пробен анализ. По-скоро е експеримент, ако зададете първоначалните размери и настройки и след това отбележите или наблюдавате активността на GC и запишете констатациите. След това, да речем, след 8-10 стартирания сравнявате бележките и виждате кое работи за вашето приложение и кое не. Наистина е интересна и тежка работа.

person Nazgul    schedule 07.12.2014