JavadansDocker:bonnespratiquesSpeakersCharlesSabourdin(Freelance),Jean-ChristopheSirot(Docker)Format:ToolsinactionDate:18avril2018DansceToolsinAction,CharlesetJean-Christopheréalisentdifférentstestsàpartirdel’applicationJavadisponibledanslerepoGitHubjcsirot/resourcesmonger.Cetteapplicationestpackagéesousformed’unFatjaretdisposed’unDockerfile.Test1L’applicationconsommetoutelaRAMdelamachine,àsavoir256Mo.Surprise:pasd’OutOfMemoryError(OOME)nid’exception.Unsimplemessage«Killed».Test2LesspeakersaugmententlaRAMà512.CettefoisontombesurunOutOfMemoryError:JavaHeapSpace.Test3LeXmxestaugmentéà1024.L’applicommenceàramerpuistombeenOOME.Le–m512MpréciseàDockerlaquantitédemémoiredisponibledansleconteneur.Lorsqueleprocessusconsommeplusdemémoirequedonné,l’OStueleprocessus.Pourtant,l’applicationaréussiàutiliser848ModeHeap.Explication:utilisationduswapquipermetdefairebasculerlamémoirevivesurledisque.Lorsqu’iln’yaplusdeplace,l’OScommenceàécriresurledisquelecontenudelaRAM.Ily’adesdéplacementsdedonnéesRAM<->Disquedanstouslessens.D’oùl’applicationquirame.Onpourraitforcerl’OSàneplusutiliserleSwap.OptionDocker:--memory-swapiness=0L’applicrasheplusvite,sansramer.L’allocationduHeapestmontéà488Mo.Commentaffecterlabonnemémoire?Aligner–met–Xmxrequiertuneformulecomplexeàétablir.RecommandationdeDocker:utiliserJava9etnonJava8.LesdéveloppeursdelaJVMsesontposéslaquestion.Dockerutiliselemécanismedescgroup.Lorsqu’ondémarreunconteneur,onpeutfixerunelimitedemémoire.DepuisJava9etJava8update131,desflagsexpérimentauxontétéajoutésàlaJVM:UnlockExperimentalVMOptionsetUseCGroupMemoryLimitForHeap.LaJVMutilise¼delamémoiredisponible(siXmxnonspécifié).EnJava10,cesoptionsnesontplusexpérimentalesetcorrespondentmêmeaucomportementpardéfaut(sipasdeXmx).Recommandation:enleverleXmx.

Laversion10deJavaapporteunemeilleureintégrationdanslesconteneursDocker.SlidedeconclusionduToolsinaction:

Questionsouvertes:- Oùmettrecesoptionsdeparamétragemémoire:orchestrateur,Dockerfile?- Lesoutilsdebuild:pluginmavenfabricate?utilisationdejlinkpouravoirdes

versionsdeJVMpluspetites