Vi bruger Python en del hos Zendesk til at bygge machine learning (ML) produkter. Et af de almindelige ydelsesproblemer, vi er stødt på med maskinlæringsapplikationer, er hukommelseslækager og spikes. Python-koden udføres normalt i containere via distribuerede behandlingsrammer såsom Hadoop, Spark og AWS Batch. Hver container er tildelt en fast mængde hukommelse. Når udførelsen af koden overskrider den angivne hukommelsesgrænse, vil containeren blive afsluttet på grund af fejl uden for hukommelsen.
En hurtig løsning er at øge hukommelsesallokeringen. Dette kan imidlertid resultere i spild af ressourcer og påvirke produkternes stabilitet på grund af uforudsigelige hukommelsesspidser. Årsagerne til hukommelseslækager kan omfatte:
- lingering af store objekter, som ikke frigives
- referencecyklusser i koden
- underliggende biblioteker/C-udvidelser, der lækker hukommelse
En nyttig øvelse er at profilere hukommelsesforbruget i applikationerne for at få en bedre forståelse af kodens og de anvendte underliggende pakkeres pladsudnyttelse. Dette indlæg dækker:
- profilering af programmets hukommelsesforbrug på tværs af tiden
- hvordan man inspicerer hukommelsesforbruget på en specifik del af programmet
- tips til fejlfinding af hukommelsesproblemer
Du kan se på hukommelsesforbruget, der varierer på tværs af tiden under udførelsen af Python-koden ved hjælp af pakken memory-profile.
# install the required packages
pip install memory_profiler
pip install matplotlib# run the profiler to record the memory usage
# sample 0.1s by defaut
mprof run --include-children python fantastic_model_building_code.py# plot the recorded memory usage
mprof plot --output memory-profile.png
Optionen include-children vil inkludere hukommelsesforbruget for alle underprocesser, der er spawnet via den overordnede proces. Graf A viser en iterativ modeltræningsproces, som får hukommelsen til at stige i cyklusser i takt med, at der behandles batches af træningsdata. Objekterne frigives, når garbage collection starter.
Hvis hukommelsesforbruget vokser konstant, er der et potentielt problem med hukommelseslækager. Her er et dummy-eksempelscript til at illustrere dette.
Det er muligt at sætte et breakpoint i debuggeren, når hukommelsesforbruget overstiger en vis tærskelværdi ved hjælp af indstillingen pdb-mmem, hvilket er praktisk til fejlfinding.
Hukommelsesdump på et tidspunkt
Det er vigtigt at forstå det forventede antal store objekter i programmet, og om de skal duplikeres og/eller transformeres til forskellige formater.
For yderligere at analysere objekterne i hukommelsen kan der oprettes et heap dump under bestemte linjer af koden i programmet med muppy.
Et andet nyttigt bibliotek til hukommelsesprofilering er objgraph, som kan generere objektgrafer for at inspicere objekternes afstamning.
Stræb efter hurtig feedback loop
En nyttig fremgangsmåde er at oprette en lille “testcase”, som kun kører den pågældende kode med hukommelseslækage. Overvej at bruge en delmængde af de tilfældigt udtagne data, hvis det tager lang tid at køre alle inputdata.
Kør hukommelsesintensive opgaver i en separat proces
Python frigiver ikke nødvendigvis hukommelse straks tilbage til operativsystemet. For at sikre, at hukommelsen frigives, efter at et stykke kode er blevet udført, skal det køres i en separat proces. Denne side indeholder flere oplysninger om garbage collection i Python.
Debugger kan tilføje referencer til objekter
Hvis der anvendes en breakpoint-debugger som f.eks. pdb, vil alle objekter, der oprettes og refereres manuelt fra debuggeren, forblive i hukommelsesprofilen. Dette kan give en falsk fornemmelse af hukommelseslækager, hvor objekter ikke frigives i tide.
Påpasselig for pakker, der kan være utætte
Nogle Python-biblioteker kan potentielt have hukommelseslækager. F.eks. pandas har en hel del kendte problemer med hukommelseslækager.
Hyggelig jagt!