6/19/2017 JavaMemorySizingprocedure(Pragmaticapproach)|SAPBlogs

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

Physicalmemory Recommended Recommended

Upto
Category requirement[GB] number heapsize[GB]
concurrentusers
alljavaservers ofservernodes perservernode

S 100 12GB 2 4

M 1.000 20GB 2 8

L 5.000 80GB 6 12

XL 10.000 160GB 9 16

more contactSAP contactSAP contactSAP contactSAP

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