Det store Skype for Business minnemysteriet

• Gjelder for:

  Skype for Business

Denne artikkelen ble skrevet av Kenn Guilstorf, Skype for Business Escalation Engineer.

Som eskaleringsingeniør hjelper jeg kunder med noen av de mer "persnickety" Skype for Business problemene. I det siste har jeg mottatt ganske mange tilfeller som er "ytelsesbaserte" – i utgangspunktet vil klager som Skype for Business er trege eller trege, ikke tillate programdeling eller bare bruker for mye minne. Mange ganger viser en undersøkelse av disse tilfellene at brukeren har latt Skype for Business kjøre i flere uker, og over tid har minnet krøpet opp til det påvirker ytelsen. Jeg har til og med lagt merke til det selv når jeg lar Skype kjøre i lang tid. Hva gjør Skype, og hvorfor holder det så mye minne? (Her er et lite hint: Dette er normalt og etter utforming. Ingenting er galt – alle opprinnelige programmer kjører inn i dette.)

Hvor mye minne kan det tygge gjennom?

Det første trinnet for å løse et problem er å forstå problemet, og det første trinnet for å forstå et problem er å definere det. Dette er ikke så enkelt å gjøre som det høres ut.

Når Skype for Business (SfB) først starter, er minnebruken sammenlignbart liten (hvis du kan telle 100 MB som liten). Vi kan se dette i et hvilket som helst antall verktøy, for eksempel Oppgavebehandling:

Figur 1: Ikke la deg lure: Lync.exe er prosessnavnet for SfB (32-biters versjon)

Over tid kommer mengden minne som prosessen bruker, til å vokse. Hvor stor den vokser, bestemmes av hvor mye Skype som brukes, hva den brukes til og så videre. Her er for eksempel den samme klienten etter ca. 24 timer:

Figur 2: Samme SfB 24 timer senere

Skype har derfor brukt ca. 32 MB på 24 timer. Det er ikke mye, ikke sant? Det er det egentlig ikke – før jeg forklarer at Skype bare satt inaktiv i alle disse 24 timene. I utgangspunktet begynte jeg å Skype for Business på en datamaskin, låste den og ventet omtrent 24 timer før jeg låste den opp. I bruk ville tollen vært mye høyere – spesielt hvis jeg ble med i møter, brukte appdeling eller skrivebordsdeling i disse møtene, brukte direktemeldinger og så videre. Jeg har sett tilfeller der Skype for Business minnebruk økte til 300–500 MB på én enkelt dag. Ting kan bli terninger etter én eller flere ukers bruk – spesielt på den langt mer minnebegrensede 32-biters klienten.

Vis meg minnet

Det finnes mange verktøy som kan profilere minne. En av de mest populære – i hvert fall hos Microsoft – er SysInternals-verktøyet VMMap, tilgjengelig på VMMap v3.26. Vi kan bruke det til å se på prosessminnet, og se om vi kan profilere Skype for Business minne.

Når du har lastet ned VMMap, kjører du det. Når den starter, åpnes en prosessliste slik at du kan velge prosessen du vil undersøke. Jeg velger lync.exe og klikker OK.

Figur 3: VMMap ved start

Deretter ser du en grafikk som er en flerfarget representasjon av gjeldende minneprofil for den kjørbare filen du har valgt – Lync.exe, i dette tilfellet.

Figur 4: Starter VMMap for nylig startet Lync.exe

Det er mye informasjon her, og beskriver det hele ville fylle opp ett eller flere blogginnlegg av seg selv. Hvis du er interessert, finnes det flere flotte bøker og nettartikler som kan bidra til å forklare det. (Personlig anbefaler jeg "Advanced Windows" av Jeffrey Richter – for øyeblikket tom for utskrift, men fortsatt utmerket i å forklare hvordan minnet fungerer. Du kan finne brukte kopier av det i din favoritt bokbutikk.)

Som du kan se, justeres ikke minnet som vises i Oppgavebehandling , i samsvar med noen kategori i VMMap. Oppgavebehandling er en mer generalisert representasjon. det er nøyaktig, det teller bare ikke alt. VMMap er mye mer omfattende.

Her er Skype-forekomsten vår etter 24-timers ventetid:

Figur 5: VMMap for Skype etter 24 timer

Hvor er minnet?

Hvis du sammenligner hver enkelt kategori, er det ingenting som står i kø. Det er vanskelig å finne ut hva som forbruker minnet, fordi minnekategoriene varierer etter hvert som objekter og minneforespørsler utføres og frigjøres, og minnet blir reservert og forpliktet til lagring av ulike objekter. «Kunnskapskjernen» (i forbindelse med denne bloggen, likevel) er «Gratis»-kategorien. I vårt eksempel er «ledig» minne all tilgjengelig plass som er «reservert» for den kjørbare Lync-filen. Men bare en bestemt type "forpliktet" minne vises i Oppgavebehandling. Det reserverte minnet telles ikke fordi det ikke er i bruk.

Så, hvor er minnet? Det blir vanskelig å finne ut fordi minnet ikke går tapt. I motsetning til folkelig tro ble ikke Skype-teamet subsidiert av produsenter av skrivebordsminne. Det finnes ingen skadelig plan for å få kunder til å oppgradere systemer eller minne. Dette er ikke engang et tilfelle av planlagt foreldelse. Sannheten er litt vanskeligere å forklare.

La oss gå litt tilbake for å gjøre ting klarere. Når du starter den Skype for Business klienten for første gang, har den et relativt lite minneavtrykk – vanligvis 100 MB eller så, avhengig av hvor mange kontakter den holder oversikt over for deg og andre kostnader (du kan tydelig se dette i dataene ovenfor). Etter noen dager vil du legge merke til at dette fotavtrykket vokser flere hundre tusen byte til flere megabyte. I enkelte situasjoner kan dette være et problem , men det er ikke nødvendigvis et problem i Skype for Business seg selv. Snarere er det en effekt av Windows-programmeringsparadigmet og hvordan det håndterer minne opprinnelig.

Windows-programmering hva?

Jeg skal bare gi en forenklet visning av Windows-minne her. Windows-minne håndteres gjennom dyre (i form av datasykluser og ressurser) prosedyrer kjent som tildelinger og de-tildelinger. Når et program trenger minne, blir Windows bedt om å tildele det. Når det er ferdig med minnet, ber programmet Windows om å fjerne allokering. Internt går Windows gjennom flere prosesser for å administrere minneforespørslene.

Når en forespørsel utføres, kontrollerer Windows minnet som den allerede har forpliktet seg til prosessen, men at prosessen ikke bruker. Windows er ute etter å se om det er en stor nok minneblokk å bruke. Hvis det er det, bruker systemet det og går på sin lystige måte. Hvis det ikke er det, kontrollerer den reservert minne. Hvis det er en stor nok blokk med reservert minne, lagres den (i operativsystemdefinerte biter kalt «sider») og lagrer variabelen i den. Minnet er nå lagret, og vi har nettopp økt minnekapasiteten til den kjørbare filen.

Hva skjer hvis det ikke er nok reservert minne til å håndtere forespørselen? Operativsystemet prøver å reservere mer minne – hvis det kan det. Her er forskjellen mellom 32-biters arkitektur og 64-biters arkitektur. En 32-biters prosess kan bare bruke maksimalt 4 GB minne. Dette er fordi 4 GB er det maksimale beløpet som et 32-biters register kan adressere. (En bit kan bare inneholde en 1 eller 0 – binær. Derfor betyr 32 biter at 2³² er den høyeste adressen som er tillatt). Takket være 32-biters arkitektur tilordnes bare ca. 2 GB av dette minnet til selve prosessen, resten som brukes av operativsystemet til å tilordne vanlige dll-adresser, ta vare på vanlige kjernemodusobjekter og så videre. I et 64-biters system kan de 64-biters lange registrene håndtere 2⁶⁴, noe som viser seg å være omtrent 18 exabytes. Windows begrenser imidlertid kunstig mengden minne som er tilgjengelig for å være reservert for mellom 2 terabyte og 4 terabyte (TB), avhengig av Windows-versjonen.

Når minnet er reservert, blir det forpliktet og deretter brukt som før. Avdelingsprosessen er i stor grad det motsatte - bortsett fra en eller to små, men viktige detaljer.

Først, med mindre du blir bedt om det, fjerner Windows aldri minnet. Når minnet er avdelt, merkes det som ledig i Windows-minnekartet. Uansett hva det holdt er fortsatt der og vil forbli der til det er overskrevet av en annen tildeling. Deretter opphever Windows sjelden minne med mindre du blir bedt om å gjøre det. Som jeg sa tidligere, minneoperasjoner er ganske ressurs-dyrt. Så hvis et program trengte minnet som ble tildelt tidligere, antar Windows at det kan trenge dette minnet på nytt, og vil vente med å slette minnet til det absolutt må. Til slutt samler Windows aldri opp minne. Dette betyr at minne som Windows frigjør aldri blir «aggregert», og blokker med ledig minne blir aldri «flyttet sammen» for å lage større blokker med ledig minne. (Alle disse funksjonene er samlet i en kategori som kalles "søppelinnsamling". .NET Framework har noen søppelinnsamlingsfunksjoner. Skype for Business er imidlertid et opprinnelig eller non-.NET program.)

Skype for Business behandler mange objekter hvert sekund som varierer i størrelse. Det må gjøre dette for å være det fantastiske verktøyet som vi vil at det skal være. Vi ber om å administrere kontakter, administrere kalendere (møter), sende direktemeldinger med venner, slektninger og kolleger, og til og med snakke med dem ved hjelp av både tale og video, dele skrivebord eller vinduer og så videre. Vel, for å sitere den avdøde, store Robert Heinlein, blant andre: "Det finnes ikke noe slikt som en gratis lunsj."

Behandling av så mange objekter av slike forskjellige og ofte variable størrelser oppretter tildelinger og de-tildelinger av store biter av minne. Over tid forårsaker dette minnefragmentering – til tider alvorlig – som øker minnekapasiteten til Skype for Business.

Et eksempel kan bedre illustrere dette punktet. La oss anta at Skype (eller et opprinnelig program, egentlig) tildeler 64 objekter, nummerert 1-64, som er 4 K byte hver i størrelse:

Figur 6: 64 objekter, hver med 4 kB minne

Dette fører til en minnetildeling og forpliktelse på 256 kB. La oss nå anta at programmet ikke krever de partallsobjektene, slik at det frigir dem:

Figur 7: Hvis du frigir alle de partallsobjektene, frigjøres 128 kB minne!

Hvis du ser på det store bildet av det totale minnet (ved hjelp av VMMap eller et lignende verktøy), ser du at en av de forpliktede kolonnene (sannsynligvis i Heap-delen , men det avhenger av nøyaktig hvordan programmet ba om minne) har 128 KB mindre, og gratisdelen har vokst med 128 kB. I Oppgavebehandling eier programmet nå bare 128 KB byte med minne.

La oss nå anta at programmet vårt har ett enkelt 8 KB-objekt som det må lagre. Dette bør være enkelt. Tross alt har den 128 KB gratis. Hvis du prøver å lagre objektet på 8 KB, opprettes det imidlertid en ny minnereservasjon i stedet for å lagre minnet på 128 kB ledig plass. Dette er fordi hvis du ser på minnet, kan du se at det fortsatt er segmentert i 4 KB-biters biter! Windows har ikke en stor nok minneblokk til å inneholde objektet på 8 KB, så det må reservere og lagre mer minne i programmet.

Dette er et ganske contrived eksempel, men det illustrerer problemet med Skypes minnebehandling. Skype administrerer et stort antall objekter som ikke har en lett definerbar størrelse. Alle disse objektene har en variably lengde. Dette betyr at når objekter lagres og frigjøres , spesielt over en lang tidsperiode, for eksempel dager eller uker , kan minnefragmenteringen bli alvorlig, og fordi Windows må tildele mer minne for lagring av de nye objektene, øker minnefotavtrykket for mye.

Når dette forårsaker problemer i 32-bitersklienten, foreslår vi ofte at du flytter til 64-bitersklienten fordi minnet er langt mindre begrenset der, takket være 64-biters vs 32-biters arkitektur. Overdreven minnevekst kan blant annet føre til treghet i selv 64-biters klienten. Disse andre vurderingene inkluderer samlet systemminne, diskhastigheter (fordi programminne vanligvis støttes av virtuelt minne i Windows-sidevekslingsfilen), hvor mange andre programmer som er åpne og så videre. I begge tilfeller, etter hvert som Skype for Business minnefotavtrykk vokser over tid, desto verre vil det fungere. I 32-biters klienttilfellet kan dette føre til at de større objektene som Skype krever – for eksempel den interne bufferen for programdeling – går tom for plass og forårsaker feil.

For å være rettferdig er minnet bare én ressurs som brukes over tid – men det er det mest åpenbare. Bruk av håndtaket kan øke, tråder vil øke over tid, sidevekkede utvalgsminner vil øke og så videre. Hver av disse økningene kan ha innvirkning på prosessen og, i enkelte tilfeller, på hele operativsystemet. Dette er en av de utallige grunnene til at vi foreslår – selv for 64-biters klienten – at brukere avslutter og starter Skype på nytt daglig (eller minst ukentlig) som anbefalt fremgangsmåte.

Hva gjør jeg med dette, og kan jeg tvinge Skype til å starte på nytt?

Det finnes flere måter å fremtvinge en Skype-omstart på, men det finnes ingen enkel og beste måte. En måte, selvfølgelig, er brukerutdanning. Brukere er arbiters av deres skrivebordsbruk i de fleste tilfeller, så det er pragmatisk å lære dem å logge av og lukke Skype når de forlater for dagen. Dette kan også gjøres som et obligatorisk trinn ved å skrive et egendefinert skript eller en kjørbar fil, og deretter kjøre én som oppgave i Oppgaveplanlegging. Denne tilnærmingen er litt ham-fisted, og kan føre til at Skype sykler selv når den er "i bruk" (selv om dette kan reduseres noe gjennom Oppgaveplanlegger-forhold). Det finnes også tredjeparts muligheter for skrivebords- og datamaskinadministrasjon, potensielle BIOS-alternativer og så videre.

Poenget er at det er best for Skype for Business å sykle daglig – eller i det minste ukentlig. Hvis du kan lære opp brukerne til å resirkulere Skype for Business regelmessig – eller i det minste når det blir rart – vil du sannsynligvis ha mange færre brukerstøtteanrop og mange flere fornøyde brukere.