Professional Documents
Culture Documents
Introduction
SAPdeliversmultiplejavabasedproducts,runningontopofSAPNetweaverJavaplatformusingSAPJVM[see
1].
Oftentherequiredjavamemoryiscalculatedbyapplyingsomeratio,forexample4GBmemoryper1000
SAPS[see2]orisdeterminedinexperimentalwayforaconcreteusage,orevenitisnotcalculatedatallbutlater,
inproduction,changestoJVMparametersareappliedasreactiontoalreadyexperiencedjavamemoryproblems.
Thisblogsuggestsapragmaticapproachtocalculatetherequiredmemoryforjavaapplicationsbasedondefined
applicationmemoryconsumptionmetrics(KPI[see3]).Itcalculatestheamountofphysicalmemorywhichshould
beavailableonthehardwareandrecommendsbestfitconfiguration(JVMsettingsandnumberofJavaserver
nodes)oftheSAPJavaServercluster.
BeawarethatJavaMemorySizingisonlyrelevanttoapplications,whichdonotintroducelogicalmemory
leaks[see4]thejavamemorysizingpreventsonlyfrommemoryshortagesituations,whicharenotleaks.
[1]SAP
JVMhttp://help.sap.com/saphelp_nwce10/Helpdata/EN/47/dc90b4ef17452289f9128b8c2bbd77/content.htm
[2]SAPShttp://www.sap.com/campaigns/benchmark/measuring.epx
[3]KPI=KeyPerformanceIndicators
[4]Memoryleakexamplesinfollowingarticles:http://www.ibm.com/developerworks/library/j
leaks/andhttp://www.javaworld.com/javaworld/javaqa/199908/04qaleaks.html
ShortoverviewonJVMMemoryManagement
ItistypicalforJavaapplicationsthat
mostofthecreatedobjectsbecomeunusedverysoon
manyobjectsandclasses,onceinstantiated,remaininmemoryforalongtime
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 1/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
Toservetothisreality,JavaVirtualMachineimplementsaconceptofseparatememoryareasfordifferentages
andtypesofobjects/classes:younggeneration,tenuredgenerationandpermanentgeneration.
TheJavaVirtualMachine(JVM)managesobjectsdeallocationautomaticallyusingvariesgarbagecollection
algorithms.Nowadaysareinventedandimplementedmanyintelligentgarbagecollectionalgorithmswithmultiple
configurationparameters,whichoptimizethefrequencyofoccurrenceandminimizethedurationofgarbage
collection.
Thegarbagecollectiondurationdependsonthegarbagecollectionalgorithm,thesizeof
theyoung,tenuredandpermanentgenerationarea,theCPUprocessingspeed,somespecificinfluencingfactors
likeimplementationoffinalize()methodofjavaobjects,andsoon.WithbiggerheapsorwithlesspowerfulCPUs,
thedurationofbothsmallandmajorgarbagecollectionislonger.Memorypagingincreasesthedurationofthe
garbagecollectiontounacceptablylongexecutiontimes,andthusitisabsolutelyessentialtohavethecomplete
javaheapinsidethemainmemoryofthemachine.
Examplefordurationofsmallgarbagecollection
OnCPU@2.66GHz,Xms=4096MXmx=4096MXX:PermSize=512MXX:MaxPermSize=512M
XX:NewSize=820MXX:MaxNewSize=820M,theminor(small)garbagecollectiontakesabout0.80.9
seconds.
Examplefordurationoffullgarbagecollection:
OnCPU@2.66GHz,Xms=4096MXmx=4096MXX:PermSize=512MXX:MaxPermSize=512M
XX:NewSize=820MXX:MaxNewSize=820M,themajor(full)garbagecollectiontakesabout910
seconds.
Withthemajor(full)garbagecollectiontheentireheapmustbeexaminedforunnecessaryobjects,that
iswhyitismuchslowercomparedtosmallgarbagecollection.
SAPrecommendstousetheJVMparametersXX:+UseConcMarkSweepGCandXX:+UseParNewGCto
enableparallelgarbagecollectionalgorithms.
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 2/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
SAPrecommendsthatthevaluesforJVMparameterspairsXmsandXmx,XX:PermSizeand
XX:MaxPermSize,XX:NewSizeandXX:MaxNewSizeshouldbesettosamevalueinthiswayheapareaswill
notresizeatruntime,becausetheresizeisassociatedwithworstperformance.
Usuallycustomerschooseheapsizes(XmsandXmx)between2GBand8GBperJavaServernode.Larger
heapsarenotverycommon,thoughpossible.
YoungGeneration
Theyounggenerationconsistsofoneedenspaceandtwosurvivorspaces.Objectsareinitiallycreatedin
theedenspace.Onesurvivorspaceisemptyatanytime,andservesasadestinationofanyliveobjectsthatare
notcollectedbytheminor(small)garbagecollectionfromtheedenspaceandtheothersurvivorspace.Objects
arecopiedbetweensurvivorspacesuntiltheyareoldenoughtobecopiedtothetenuredgeneration.When
thesurvivorspaceistoosmalltoholdthesurvivingobjects,theoverflowingobjectsarecopieddirectlyinto
thetenuredgeneration.
TenuredGeneration
Ifintenuredgenerationisleftlessfreespacethanthetotalsizeoftheedenspaceandonesurvivor,major(full)
garbagecollectionisstarted.Thesituationisknownasyounggenerationguarantee.Forthisreason
thetenuredgenerationsizedependsonthesizeoftheyounggenerationsizeandpracticallyshouldbe
significantlybiggerthantheyounggenerationspace.
PermanentGeneration
Thepermanentgenerationholdsdataofclassesandmethods.Typicallyitscontentisstableovertimeand
shortageofspaceinthepermanentgenerationisrarelyoccurring,unlessprogrammingpatternswithruntime
class/methodsgenerationareusedbytheapplication.Whenthepermanentgenerationspaceneedstobe
cleaned,amajor(full)garbagecollectionistriggered.
Nativecodearea
TheJVMimplementationneedsspaceoutsidedefinedheap,letsnameitNativecodearea.Considerat
maximum1GBperJVMforit.
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 3/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
Shortoverviewonbasicmemoryconsumptionmetrics(KPI)
inSAPJavaApplicationServerenvironment
SAPdefinedmemorymetrics(KPI)todeterminethememoryconsumptionprofileofapplicationsrunningontopof
NetWeaverJavaApplicationServer.InthearticleBestPracticesforJavaPerformance&LoadTests[see5]are
presentedthreememoryKPIs(slide11,12,13and14)FrameworkSpace,SessionSpaceandProcessing
SpacewithdescriptionofcorrespondingmeasurementprocedureandtwogarbagecollectionKPIs(slides16and
17)GCdurationandGCinterval.
[5]https://service.sap.com/~form/sapnet?
_SCENARIO=01100035870000000112&_SHORTKEY=01100035870000630780&_OBJECT=011000358700006399802006E&
FrameworkSpace[MB]
ThesocalledFrameworkSpaceisfilledwithobjectscreatedduringinitializationofjavaserverservices,libraries,
applications,etc.andobjectsofsharedcaches,pools,etc.Suchobjectstypicallylivefortheentirelifetimeofthe
javavirtualmachineandthereforearealwayspromotedtothetenuredgeneration.Thecorrespondingtothose
objectsclassesandmethods,definedasPermFrameworkSpace,stayinpermanentgenerationforthecomplete
livetimeofjavaserver.
ThemeasurementforFrameworkSpaceandPermFrameworkSpaceisdoneviaanalysisofheap
dumps,takenafterwarmup(executionwithdifferenttestusersofthemainfunctionalscenarios)ofthe
sizedapplication.Itisimportantthatatthetimewhentheheapdumpistakentheusersarenolonger
activeontheservernodetheyshouldbeeitherloggedoutortheirsessionsshouldhaveexpired.
UseMemoryAnalyzertool.
UserSessionSpace[MBpersession]
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 4/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
ThesocalledSessionSpaceisfilledwithobjectsrelatedtotheusersessionandtemporarycacheswhichare
removediftheuserleavesthesystemduetologout,ortimeout.Auserisconnectedtothesystemforatleast
severalminutestheSessionSpaceobjectsusuallylivelongenoughtobepromotedtotenuredgenerationand
fromtenuredgenerationareatheycouldberemovedonlywithmajor(full)garbagecollection.
ThememorymeasurementforuserSessionSpaceanduserPermSessionSpaceisusuallydone
withanalysisofaheapdump,takenwhilemultipleusersareloggedintothesystemandareexecuting
differentdialogstepsoftheimportantfunctionalscenariosofthesizedapplication.
UseMemoryAnalyzertool.
ProcessingSpace[MBperdialogstep]
TheProcessingSpaceisfilledwithshortlivingobjectswhichtypicallyarereadytobeimmediatelygarbage
collecteddirectlyintheyounggenerationspaceafterreplyingtoauserrequest[see6]iscompleted.
ThememorymeasurementforProcessingSpaceisbasedonthetotalsizeofallobjectallocations
doneinthethread,ormultiplethreads,whichareexecutingtheuserrequest.TheProcessingSpace
includesnotonlytheobjectswhicharetemporaryallocatedandgarbagecollectedforprocessingthe
userrequestbutalsothoseobjectswhichwillbecomepartofcachesorsessionspace,i.e.willbe
promotedtotenuredgenerationaftersmallgarbagecollection.
UseSAPJVMProfilertool.
[6]UserrequestcanbeahttprequesttoJavaserverfrombrowser,butaswellanyotherremoteorlocalcallexecutedby
Javaserverreceivedandansweredonanyofthecommunicationprotocols,whicharesupported.Forthepurposeofthis
paper,itcouldbealsoanyperiodictask,whichisactivatedandexecutedontheserver,evenifnoexternalcommunication
isinvolved.
GoalofJavaMemorySizing
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 5/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
Thegoalofjavamemorysizingistominimizethefrequencyanddurationofgarbagecollection,
i.e.todeterminewithwhich(applicationspecific)sizeof
younggeneration,aminimumamountofobjectswouldbecopiedintothetenuredgeneration
tenuredgeneration,aminimumnumberoffullgarbagecollectionswouldbeexecuted
permanentgeneration,aminimumnumberoffullgarbagecollectionswouldbeexecuted
IfbestconditionsforminimumdurationofGCareinplaceviaselectionofthebestoptimizedgarbagecollection
algorithm,fastCPUmodelandadequatesizesofgenerationareas,wecaneffectivelydefinetargetgarbage
collectionintervalstoensurethatgarbagecollectiondoesnothappentoofrequently.
Thefrequency,definedasintervalbetweentwosuccessivegarbagecollection(GC)occurrences,isarequired
inputparameterformemorysizing.
LetsdefineIsgcandIfgc
Isgc=intervalofsmallgarbagecollection(inseconds),forexample3seconds
ItisrecommendedthatIsgcislongercomparedtoaverageresponsetimeforparticularenduser
request.Forexample,iftheaverageresponsetimeperrequestis12secondsthentargetintervalof3
secondsisgoodenough.Iftheaverageresponsetimeis3seconds,thenitisbettertoselecttarget
intervalforsmallgarbagecollectionabout45seconds.Theintentionistomakesurethatbetweentwo
smallgarbagecollectionssomeenduserrequestsarecompletedandthusmorememorycouldbe
recycled.Ifmanyrequestsarestillinprocessthenwithsmallgarbagecollectionmemorycannotbe
recycled(stillinuse)andmightbepromotedtothetenuredgeneration.
Ifgc=intervaloffullgarbagecollection(inseconds),forexample1020seconds(17minutes)
TheIfgcintervalshoulddependontheaveragedurationofendusersession.Ifusersessiononaverage
is15minuteslongthenatargetfullgarbagecollectionintervalof1617minuteswillbeok.Iftheuser
sessionisabout30minuteslong,thetargetfullgcintervalshouldbeadjustedtohighervalue.Whenfull
garbagecollectionisrunning,butusersessionsarestillactiveandthesessionmemorycannotbe
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 6/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
recycled,thesystemperformanceisusuallybadwitharealdangerofcrashwithOutofMemory
(OOM)error.
FormulasforJavaMemorySizing
Thetotalamountofmemorywhichisrequiredtoholdallusersessionsiscalculatedlike
(F1)TotalSessionsSpace[MB]=Numberofconcurrentusers*UserSessionSpace[MB]+
Numberofnewsessionspersecond*UserSessionSpace[MB]*Ifgc
Theusersessioncouldhavedifferentsizeafterexecutionofdifferentdialogstepsofthescenarios.For
pessimisticsizingtakethemaximummeasuredsessionsize(peaksessionsize)amongallusersessionsandfor
normalsizingtaketheaverageusersessionsize.
Notonlythecurrentlyactivesessionsareincludedinthesizingbutalsothenewsessionswhichwillbe
createdbetweentwosequentialcollectionsareconsideredandplannedforsessionspace.
Iftenuredgenerationissizedonlyforthecurrentlyalivesessions,theneverynewcreatedusersession
maytriggerfullgarbagecollection.Thisfullgarbagecollectionwillnotabletocollectenoughunused
SessionsSpacememory,becausemostoftheusersessionsarestillaliveandverysoonanewfull
garbagecollectionwillberequiredandthefrequencyoffullgarbagecollectionswillincrease.Toavoid
thiseffectinthetenuredgenerationtheremustbeplannedcapacitytohandlenewincomingsessions
whichreplacetheloggedoutorexpiredsessionswithoutneedthatthoseunusedobjectsare
immediatelygarbagecollected.
Insomeapplicationimplementations,classesandmethodsarecreatedatruntime(socalledruntime
class/methodgeneration).Insuchcasesthesizeofpermanentgenerationareawilldependonthenumberof
concurrentuserstoothedeltagrowthperusersessionwillbeapplicationspecificanddeterminedasadditional
memoryKPI:PermUserSessionSpace[MB/user].
(F1a)TotalPermanentSessionsSpace[MB]=
Numberofconcurrentusers*PermUserSessionSpace[MB]+Numberofnewsessionsper
second*PermUserSessionSpace[MB]*Ifgc
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 7/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
Thereisrelationbetweenthenumberofusersessionsandtherequestspersecond,whichareprocessed:
Requestspersecond=(Numberofconcurrentusers)/(Averageresponsetime[s]+Thinktime
[s])
Giventhis,itiseasytocalculatethetotalprocessingspacerequiredbyjavaobjects,generatedbetweentwo
sequentialsmallgarbagecollectionsinIsgcinterval
(F2)TotalProcessingSpace[MB]=Requestspersecond*Processingspace[MB]*Isgc
WithSAPJavaServerthereisnomechanismtosplitthetotalrequiredFrameworkSpaceorPermFramework
SpaceintopartsandputittodifferentJVMs.ThereforetherequiredFrameworkSpaceorPermFramework
Spaceisallocatedwithinthetenuredgenerationandwithinthepermanentgeneration,ofeveryJavaVirtual
Machine,i.e.oneveryJavasevernode.
ThismeansthatwitheveryJavaServernodethetenuredgenerationandpermanentgenerationsizesshould
alwaysbebiggerthanframeworkspaces,i.e.
Tenuredgeneration[MB]>FrameworkSpace[MB]
Permanentgeneration[MB]>PermFrameworkSpace[MB]
DeterminephysicalmemoryrequirementsandJavaServerconfiguration
AfterFrameworkSpace[MB](alsoPermFrameworkSpace[MB])ismeasured,andSessionsSpace[MB](also
PermSessionsSpace[MB])andProcessingSpace[MB]arecalculatedusingformulasF1,F1aandF2,to
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 8/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
completememorysizingremainsto
Determinetheclusterconfigurationheapsizeandnumberofjavaservernodes
Heapsize[MB]=FrameworkSpace[MB]+(2*TotalProcessingSpace[MB]+TotalSessions
Space[MB])/(NumberofServernodes)
Permsize[MB]=PermFrameworkSpace[MB]+(TotalPermanentSessionsSpace[MB])/(Numberof
Servernodes)
MultiplecombinationsofNumberofServernodesandHeap(Perm)sizesarepossible.
Ifmoreservernodeswithsmallerheaparepreferred,thenthetotalphysicalmemoryrequirementwouldbe
higherduetothefactthateachserverwouldhaveownnativecodeareaforinitializationoftheJVMandthatthe
frameworkspacememoryisrepeatedineachandeveryservernode.
Forstabilityandfailoverreasonschoosejavaclusterconfigurationwithatleast23javaservernodes.
Iflessservernodeswithbiggerheaparepreferred,thenlongerdurationofthegarbagecollectionisexpected.
Avoidtoomanyservernodes,e.g.morethan10,becauseofpossibleincreasedstartuptimesincluster.
Calculatethetotalamountofrequiredphysicalmemory
Physicalmemory[MB]=NumberofServernodes*(Heapsize[MB]+Permsize[MB]+Nativecode
area[MB])
Whattodeliverassizing?
Injavamemorysizingguidelineitisnotnecessarytoprovidealldetailsofmeasuredmemory,neitherformulasfor
calculation.
Asresultofallsizingcalculations,thesizingguidelinecanlooklikeatablewherethesizingexperthasdecidedon
theoptimalnumberofservernodesandappropriateheapsizes,forexample:
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 9/10
6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs
S 100 12GB 2 4
M 1.000 20GB 2 8
L 5.000 80GB 6 12
XL 10.000 160GB 9 16
Thejavamemorysizingisapplicationspecific.Ifmorethanoneapplicationisintensivelyusedingivenjava
environment,thejavamemorysizingshouldbecalculatedforthetotalusage.
JavaApplications,whichsetinadvancememoryKPIsforsessionspace(e.g.upto5MBpersession)and
processingspace(e.g.upto10MBperrequest)andmanagetofulfillitduringdevelopmentwillhavelowmemory
requirementsandgoodperformance.
https://blogs.sap.com/2013/08/29/javamemorysizingprocedurepragmaticapproach/ 10/10