Detecting Memory Leak OnAIX.docx

Detecting Memory Leak OnAIX.docx

《Detecting Memory Leak OnAIX.docx》由会员分享，可在线阅读，更多相关《Detecting Memory Leak OnAIX.docx（12页珍藏版）》请在冰豆网上搜索。

DetectingMemoryLeakOnAIX

MethodsforIdentifyingMemoryLeaksinAIXSystems

ByBarryJ.SaadandHaroldR.Lee

Applicationmemoryleakscanbedifficulttodetectandonmodernmulti-taskingsystemswheremanyapplicationsarerunning,itcanbeevenmoredifficulttoidentifytheoffendingprocess（es）.

Thispaperwillexplorethereasonsformemoryleaks,andusingtheAIXsystemperformancetools,provideamethodologyforidentifyingthemtotheprocesslevel.Thispaperwillconsistoffourmajorparts:

（1）definitionandcausesforamemoryleakonasystem,

（2）examiningaprocessheapusingsvmonandps,（3）amethodfordetectingmemoryleaksonasystem,（4）amethodforidentifyingindividualprocesseswhichhavememoryleaks.

TheCausesforMemoryLeaks

TheJargonFileversion4.2.0definesamemoryleakas:

memoryleak

n.Anerrorinaprogram'sdynamic-store

allocationlogicthatcausesittofailtoreclaimdiscardedmemory,

leadingtoeventualcollapseduetomemoryexhaustion.Theseproblems

weresevereonoldermachineswithsmall,fixed-sizeaddress

spaces,andspecial"leakdetection"toolswerecommonlywritten

torootthemout.Withtheadventofvirtualmemory,itisunfortunatelyeasiertobesloppyaboutwastingabitofmemory（althoughwhenyourunoutofmemoryonaVMmachine,itmeansyou'vegota_real_leak!

）.

Memoryisallocatedtoaprocessesheapbyusingthemalloc（）ClibrarycallorinC++whenaclassisinstantiatedbycallinga“constructor”whichwill“setup”theclassbyallocatingtherequiredmemoryfortheclassandinitializingthemembers.Whenthememoryisnolongerrequiredbytheprocess,itisreleasedforreusebythefree（）ClibrarysystemcallorinC++whentheclassis“torndown”bycallinga“destructor”whichwillreleasethememoryforreuse.Whenaprocessterminates,alloftheprogram’sdynamic-storewhichisalsocalledtheprocessesheapandstackarereturnedtooperatingsystemforreallocationtootherprocesses.

Memoryleaksoccurwhenmemorythatisallocatedtotheheapisnotreleasedbytheprocessandtheheapwillcontinuetogrow.Overtime,theprocesswilleitherallocateallofthememoryandfillits’addressspacewhichmaycauseabnormalterminationoftheprocessoritwilluseupthevirtualmemoryandcausethekerneltotakeprotectivemeasurestopreservetheintegrityoftheoperatingsystembykillingprocessestorelievethevirtualmemorydemands.Unfortunately,memoryleaksareusuallycausedbylongrunningprocessesandthealgorithmwhichthekernelusestoreducevirtualmemorydemandsistostartkillingprocessesbasedonthe“youngest”process（mostrecentlycreated）andworkingtowardthe“oldest”.Thiscanhavetheeffectofmanyprocessesbeing“killed”beforetheoffendingprocessisdealtwith.

Duetothecomplexityofprogramsandthelevelsofmemoryallocationanddeallocationabstractioninobjectorientedprograms,memoryleaksaresometimesverydifficultifnotimpossibletocompletelyeliminate.Oneapproachtothisproblemistolimitthelifespanofaprogramwheretheprogramisterminatedbeforeanypotentialmemoryleaksareallowedtogrowenoughtobecomeaproblem.TheApachewebserverisanexampleofthisapproach.WhentheApacheserverisstarted,aparentprocessstartedwhichallocatesverylittlememoryanddoesverylittlework.Theparent’sjobistoinitiallyspawnsomenumberofchildserverprocesssetbytheStartServersdirectiveintheconfigurationfile,andthentotrytomaintainthenumberofchildserverprocessbetweentwolevelseitherbycreatingorkillingadditionalprocesses.ThiswindowissetbytheMaxSpareServersandMinSpareServersdirectivesinthestartupconfigurationfile.

MaxRequestsPerChilddirective

TheMaxRequestsPerChilddirectivesetsthelimitonthenumberofrequeststhatanindividualchildserverprocesswillhandle.AfterMaxRequestsPerChildrequests,thechildprocesswilldie.IfMaxRequestsPerChildis0,thentheprocesswillneverexpire.

SettingMaxRequestsPerChildtoanon-zerolimithastwobeneficialeffects:

∙itlimitstheamountofmemorythatprocesscanconsumeby（accidental）memoryleakage;

∙bygivingprocessesafinitelifetime,ithelpsreducethenumberofprocesseswhentheserverloadreduces.

Eachchildserverprocesseswillkeeptrackofthenumberofrequestswhichitwillhandleandafterthisnumberhasbeenreached,theprocesswilldieandreturnallofthevirtualmemorytothekernelheapforreallocation.Thefollowingsnippetisfromtheconfigurationfileinstructionpage.Noticethereasongivenforlimitingthelifetimeofthechild:

NotallapplicationshavetheflexibilityofApachetodealwithpotentialleaks.Anotherstrategyisforcompaniestoscheduleregularintervalsfortheapplicationstoberecycled.Thisinvolvesshuttingdowntheapplicationsandrestartingthem.Whilesomereboottheentiresystem,thisisnotnecessaryunlesstherearemitigatingcircumstancessuchasamaintenancepatchorarebootspecifictuningchange（e.g.changingtheasynchronoussubsystemparameters）.

Anotherformofprocessmemoryleakageiscalled“heapfragmentation”.Heapfragmentation,whichisthebaneofoperatingsystemdesign,issomethingdevelopershavehadtocontendwithsincethebeginning.Agooglesearchon“heapfragmentation”willreturnover64,000hitsillustratingthemagnitudeofthisissue.Heapfragmentationiswhenavailablememoryisbrokenintosmall,non-contiguousblocks.Whenthisoccurs,memoryallocationcanfaileventhoughthereisenoughmemoryintheheaptosatisfytherequest,becausenooneblockofmemoryislargeenoughtosatisfytheallocationrequest.

Forapplicationsthathavealowmemoryusage,thestandardheapisadequate;allocationswillnotfailduetoheapfragmentation.However,iftheapplicationallocatesmemoryfrequentlyandusesavarietyofallocationsizes,memoryallocationcanfailduetoheapfragmentation.

Heapfragmentationiscausedbynumeroussubsequentmalloc（）sandfree（）sontheprocessheapwithwidelyvaryingsizes.Thiscause“holes”toforminthecontiguousheapandunlessamalloc（）issmallenoughtousethespacewithina“hole”theprocessheapmustgrowtosatisfytherequest.

Onestrategyfordealingwithheapfragmentationistoemployatechniquecalled“GarbageCollection”.Whenarequestcannotbesatisfiedfromtheheapduetofragmentation,thegarbagecollectionroutineiscalledwhichmovesallofthe“holes”totheendoftheheap,makingallofthespaceavailableattheendoftheheap.Thisgarbagecollectionisanalogoustodefragmentingaharddrive,whichmovesalloftheunusedspacetotheend.

Someoftheearlyoperatingsystemsemployedgarbagecollectiontechniqueshoweverthiscausesveryerraticperformancefromthesystemsinceallactivityhadtostopwhilethememorywasrearranged.TheJavavirtualmachine（JVM）,whichisa“guest”operatingsystem,currentlyusesthismethodwithsimilarresults.Garbagecollectionisnotusedonmostoperatingsystemstodaydueinparttotheerraticperformanceitproduces.

Anotherstrategywhichsomeprogramsusetoeliminatethisistomanagetheheapinternallythroughtheuseofpointers.Whentheprogramstartsthereisasinglememoryallocationcalltoobtaintheheapandthentheprogramitselfwillallocateportionsoutofittosatisfytheinternalrequests.MostdatabaseprogramslikeOracleandDB2usethismethodofinternalmemorymanagement.

Operatingsystemdeveloperscontinuetoworkonmoreefficientmemoryallocationalgorithmsandincorporatethemintothekernelstoreducethisissuetooneonminimumimpact.TheWindows™developershaveintroducedaheapmanagercalledthe“LowFragmentationHeap”（LFH）whichplacestheholesinaCartesianbtreestructuresimilartotheAIX4.2–5.2mallocroutineknownasthe“Yorktownmalloc”sinceitwasdevelopedbytheYorktownresearchfacility.

Anewmalloccalledthe“watsonmalloc”isavailableonAIX5.3.TheWatsonmallocwhichiscachebasedandusesasimplifiedrbtree（red-blacktree）structureincreasesmallocperformanceaswellasreducingheapfragmentation.Thenewmalloc（）isoptimizedforlargemulti-threadedapplicationsandtimewilltellhowmuchmoreefficientitis.Formoreinformationonthismallocrefertothefollowinglink:

Refertothesection-UnderstandingtheWatsonAllocationPolicy

Fromasystemadministrationperspective,heapfragmentationisdealtwiththesamemannerasamemoryleak.Theapplicationsmustbequiescedandrestarted.

ExaminingAProcessHeapUsingsvmonandps

Foranoverviewofthevirtualmemorymanagementataprocesslevel,refertothefollowingarticlesandinfopages:

http:

//w3-

Article–UnderstandingVirtualMemoryManagement

Alsorefertothemanorinfopageonthesvmonandpscommands

Theprocessesvirtualmemoryfootprintconsistsofthreeseparateitems.Theactual

（1）heapandthe

（2）processstackwhichisaddressedby（esid）register“2”,andthe（3）sharedlibrarydatawhichisaddressedbyregister“f”.Theloadersegment“d”issharedbyallprocessesandisignored.

#svmon-nrP262188

-------------------------------------------------------------------------------

PidCommandInusePinPgspVirtual64-bitMthrdLPage

262188mamain659804784065977NNN

VsidEsidTypeDescriptionLPageInusePinPgspVirtual

23e92workprocessprivate-532633053263

AddrRange:

0..53247:

65314..65535

1f09ddworkloadersegment-3508003508

AddrRange:

0..8684

63adfworksharedlibrarydata-