Det stora Skype för företag minnesmysteriet

• Gäller för:

  Skype for Business

Den här artikeln skrevs av Kenn Guilstorf, Skype för företag eskaleringstekniker.

Som eskaleringstekniker hjälper jag kunder med några av de mer "persnickety" Skype för företag problem. På senare tid har jag fått en hel del fall som är "prestandabaserade" - i princip klagomål om att Skype för företag är långsam eller trög, inte tillåter programdelning, eller helt enkelt använder för mycket minne. Många gånger visar en undersökning av dessa fall att användaren har låtit Skype för företag köras i veckor. Med tiden har minnet kröpts tills det påverkar prestandan. Jag har till och med märkt det själv när jag lät Skype köras länge. Så, vad gör Skype, och varför håller det så mycket minne? (Här är en liten ledtråd: Detta är normalt och avsiktligt. Inget är fel – alla inbyggda program stöter på detta.)

Hur mycket minne kan det tugga igenom?

Det första steget för att åtgärda eventuella problem är att förstå problemet, och det första steget för att förstå eventuella problem är att definiera det. Det här är inte så lätt att göra som det låter.

När Skype för företag (SfB) startar första gången är minnesanvändningen jämförelsevis liten (om du kan räkna 100 MB som liten). Vi kan se att detta inträffar i valfritt antal verktyg, till exempel Aktivitetshanteraren:

Bild 1: Låt dig inte luras: Lync.exe är processnamnet för SfB (32-bitarsversion)

Med tiden kommer mängden minne som används i processen att växa. Hur stor den växer bestäms av hur mycket Skype som används, vad det används till och så vidare. Här är till exempel samma klient efter cirka 24 timmar:

Bild 2: Samma SfB 24 timmar senare

Så Skype har förbrukat cirka 32 MB på 24 timmar. Det är inte mycket, eller hur? Det är verkligen inte - tills jag förklarar att Skype bara satt inaktiv för alla dessa 24 timmar. I grund och botten började jag Skype för företag på en dator, låste den och väntade ungefär 24 timmar innan jag låste upp den. I användning skulle avgiften ha varit mycket högre – särskilt om jag gick med i möten, använde appdelning eller skrivbordsdelning i dessa möten, använde snabbmeddelanden och så vidare. Jag har sett fall där Skype för företag minnesanvändning växte till 300–500 MB på en enda dag. Saker kan bli tärande efter en eller flera veckors användning – särskilt på den mycket mer minnesbegränsade 32-bitarsklienten.

Visa minnet

Det finns många verktyg som kan profilera minne. En av de mest populära – åtminstone Microsoft – är SysInternals-verktyget VMMap, som finns på VMMap v3.26. Vi kan använda den för att titta på processminnet och se om vi kan profilera Skype för företag minne.

När du har laddat ned VMMap kör du den. När den startar öppnas en processlista så att du kan välja den process som du vill undersöka. Jag väljer lync.exe och klickar på OK.

Bild 3: VMMap vid start

Därefter visas en bild som är en flerfärgad representation av den aktuella minnesprofilen för den körbara fil som du har valt – Lync.exe i det här fallet.

Bild 4: Starta VMMap för nyligen startade Lync.exe

Det finns mycket information här, och att beskriva allt skulle fylla upp ett eller flera egna blogginlägg. Om du är intresserad finns det flera bra böcker och onlineartiklar som kan hjälpa till att förklara det. (Personligen rekommenderar jag "Advanced Windows" av Jeffrey Richter - för närvarande ur tryck men fortfarande utmärkt att förklara hur minnet fungerar. Du hittar begagnade kopior av den i din favoritbokhandel.)

Som du ser överensstämmer inte minnet som visas i Aktivitetshanteraren med någon kategori i VMMap. Aktivitetshanteraren är en mer generaliserad representation. det är korrekt, det bara inte räknas allt. VMMap är mycket mer omfattande.

Här är vår Skype-instans efter väntetiden på 24 timmar:

Bild 5: VMMap för Skype efter 24 timmar

Var är minnet?

Om du jämför varje enskild kategori visas egentligen ingenting. Det är svårt att faktiskt hitta det som förbrukar minnet eftersom minneskategorierna varierar när objekt och minnesbegäranden görs och frigörs, och minnet reserveras och sparas för att lagra olika objekt. "Kärnan av kunskap" (för den här bloggen i alla fall) är kategorin "Gratis". I vårt exempel är "ledigt" minne allt tillgängligt utrymme som är "reserverat" för den körbara Lync-filen. Men endast en viss typ av "bekräftat" minne visas i Aktivitetshanteraren. Det reserverade minnet räknas inte eftersom det inte används.

Var finns minnet? Det blir svårt att hitta eftersom minnet inte går förlorat. I motsats till vad många tror var Skype-teamet inte subventionerat av tillverkare av skrivbordsminne. Det finns ingen skändlig plan för att få kunder att uppgradera system eller minne. Det här handlar inte ens om planerad föråldring. Sanningen är lite svårare att förklara.

Låt oss backa lite för att göra saker tydligare. När du först startar Skype för företag-klienten har den ett relativt litet minnesavtryck – vanligtvis 100 MB eller så, beroende på antalet kontakter som den håller reda på för dig och andra omkostnader (du kan tydligt se detta i data ovan). Efter några dagar ser du att fotavtrycket växer flera hundra tusen byte till flera megabyte. I vissa situationer kan detta vara ett problem – men det är inte nödvändigtvis ett problem i Skype för företag sig själv. Det är snarare en effekt av Windows programmeringsparadigm och hur det hanterar minnet internt.

Windows-programmering vad?

Jag ska bara ge en förenklad bild av Windows-minnet här. Windows-minne hanteras via dyra (när det gäller datorcykler och resurser) procedurer som kallas allokeringar och avallokeringar. När ett program behöver minne uppmanas Windows att allokera det. När det är klart med minnet ber programmet Windows att avallokera det. Internt går Windows igenom flera processer för att hantera minnesbegäranden.

När en begäran görs kontrollerar Windows det minne som den redan har checkat in i processen men som processen inte använder. Windows vill se om det finns ett tillräckligt stort minnesblock att använda. I så fall använder systemet det och går på sin glada väg. Om det inte finns kontrollerar den reserverat minne. Om det finns ett tillräckligt stort block med reserverat minne checkar det in det (i operativsystemdefinierade segment som kallas "sidor" och lagrar variabeln i det. Minnet är nu incheckat och vi har precis vuxit minnesfotavtrycket för den körbara filen.

Vad händer om det inte finns tillräckligt med reserverat minne för att hantera begäran? Operativsystemet försöker reservera mer minne – om det kan. Här är skillnaden mellan 32-bitars arkitektur och 64-bitars arkitektur. En 32-bitarsprocess kan bara använda högst 4 GB minne. Det beror på att 4 GB är det maximala belopp som ett 32-bitarsregister kan hantera. (En bit kan bara innehålla en 1 eller en 0 – binär. Därför innebär 32 bitar att 2³² är den högsta adressen som tillåts). Tack vare 32-bitarsarkitekturen tilldelas endast cirka 2 GB minne till själva processen, resten används av operativsystemet för att mappa vanliga DLL:er, ta hand om vanliga kernellägesobjekt och så vidare. I ett 64-bitarssystem kan de 64-bitars långa register hantera 2⁶⁴, vilket visar sig vara cirka 18 exabyte. Windows begränsar dock artificiellt mängden minne som är tillgängligt för att reserveras till mellan 2 terabyte och 4 terabyte (TB), beroende på Windows-versionen.

När minnet har reserverats checkas det in och används sedan som tidigare. Avallokeringsprocessen är till stor del den omvända - förutom en eller två små men viktiga detaljer.

Först, om det inte begärs, "rensar" Windows aldrig minnet. När minnet har avallokerats markeras det som ledigt i Windows-minneskartan. Vad det än höll finns kvar och kommer att finnas kvar där tills det skrivs över av en annan allokering. Därefter avregistrerar Windows sällan minne om det inte begärs att göra det. Som jag sa tidigare är minnesåtgärder ganska resurskrävande. Så om ett program behövde det minne som allokerades tidigare, förutsätter Windows att det kan behöva det minnet igen och kommer att hålla minnet avstängt tills det absolut måste. Slutligen "sammansejsar" Windows aldrig minnet. Det innebär att minne som Frigörs i Windows aldrig "aggregeras" och block med ledigt minne aldrig "flyttas tillsammans" för att skapa större block med ledigt minne. (Alla dessa funktioner klumpas ihop i en kategori som kallas "skräpinsamling". .NET Framework har en del skräpinsamlingsfunktioner. Men Skype för företag är ett "internt" eller non-.NET program.)

Skype för företag bearbetar många objekt varje sekund som har variabilitetsstorlek. Det måste göra detta för att vara det fantastiska verktyget som vi vill att det ska vara. Vi ber den att hantera kontakter, hantera kalendrar (möten), snabbmeddelanden med våra vänner, släktingar och kollegor och till och med prata med dem genom att använda både röst och video, dela skrivbord eller fönster och så vidare. För att citera den framlidne, store Robert Heinlein, bland andra: "Det finns inget sådant som en gratis lunch."

Genom att hantera så många objekt av så olika och ofta varierande storlekar skapas allokeringar och avallokeringar av minnessegment av variabel storlek. Med tiden orsakar detta minnesfragmentering – ibland svår – som ökar minnesavtrycket för Skype för företag.

Ett exempel kan bättre illustrera den här punkten. Låt oss anta att Skype (eller något internt program, egentligen) allokerar 64 objekt, numrerade 1-64, som är 4 K byte vardera i storlek:

Bild 6: 64 objekt, var och en använder 4 KB minne

Detta orsakar en minnesallokering och ett åtagande på 256 KB. Nu antar vi att programmet inte kräver de jämnt numrerade objekten, så det släpper dem:

Bild 7: Om du släpper alla jämnt numrerade objekt frigörs 128 kB minne!

Om du tittar på den större bilden av det totala minnet (med hjälp av VMMap eller ett liknande verktyg) ser du att en av de incheckade kolumnerna (troligen i avsnittet Heap , men det beror på exakt hur programmet begärde minnet) har 128 KB mindre och avsnittet Kostnadsfri har ökat med 128 KB. I Aktivitetshanteraren äger programmet nu bara 128 KB byte minne.

Nu ska vi anta att vårt program har ett enda 8 KB-objekt som det måste lagra. Detta bör vara enkelt. Den har trots allt 128 KB kostnadsfritt. Men om du försöker lagra det 8 KB-objektet skapas en ny minnesreservation i stället för att minnet lagras på 128 KB ledigt utrymme. Det beror på att om du tittar på minnet kan du se att det fortfarande är segmenterat i 4 KB-segment! Windows har inte ett tillräckligt stort minnesblock för att lagra 8 KB-objektet, så det måste reservera och spara mer minne i programmet.

Detta är ett ganska intrikat exempel, men det illustrerar svårigheten med Skypes minneshantering. Skype hanterar ett stort antal objekt som inte har en lättdefinierbar storlek. De här objekten är alla variably långa. Det innebär att när objekt lagras och frigörs – särskilt under en lång tidsperiod, till exempel dagar eller veckor – kan minnesfragmenteringen bli allvarlig och eftersom Windows måste allokera mer minne för att lagra de nya objekten växer minnesfotavtrycket alltför mycket.

När detta orsakar problem i 32-bitarsklienten föreslår vi ofta att du flyttar till 64-bitarsklienten eftersom minnet är mycket mindre begränsat där tack vare 64-bitars- och 32-bitarsarkitektur. Men överdriven minnestillväxt, bland andra överväganden, kan orsaka tröghet i även 64-bitarsklienten. Dessa andra överväganden omfattar övergripande systemminne, diskhastigheter (eftersom programminnet vanligtvis backas upp av virtuellt minne i Windows-växlingsfilen), hur många andra program som är öppna och så vidare. I båda fallen, när Skype för företag minnesfotavtryck växer med tiden, desto sämre kommer det att prestera. I 32-bitarsklientfallet kan detta göra att de större objekt som Skype kräver – till exempel dess interna buffert för programdelning – får slut på utrymme och orsakar fel.

För att vara rättvis är minnet bara en resurs som förbrukas över tid – men det är det mest uppenbara. Hanteringen av användningen kan öka, trådarna ökar med tiden, sidpoolsminnet ökar och så vidare. Var och en av dessa ökningar kan påverka processen och i vissa fall på hela operativsystemet. Detta är en av de otaliga orsakerna till varför vi föreslår – även för 64-bitarsklienten – att användarna avslutar och startar om Skype dagligen (eller åtminstone varje vecka) som bästa praxis.

Vad gör jag åt detta och kan jag tvinga Skype att starta om?

Det finns flera sätt att tvinga fram en Skype-omstart, men det finns inget enskilt, bästa sätt. Ett sätt är naturligtvis användarutbildning. Användare är domare i sin skrivbordsanvändning i de flesta fall, så det är pragmatiskt att lära dem att logga ut och stänga Skype när de lämnar för dagen. Detta kan också göras som ett obligatoriskt steg genom att skriva ett anpassat skript eller en körbar fil och sedan köra något av dem som en aktivitet i Schemaläggaren. Den metoden är lite ham-fisted, och kan få Skype att cykla även när det är "i bruk" (även om detta kan mildras något genom Task Scheduler villkor). Det finns också möjligheter från tredje part för hantering av stationära datorer och datorer, potentiella BIOS-alternativ och så vidare.

Slutsatsen är att det är bäst för Skype för företag att cykla den dagligen – eller åtminstone varje vecka. Om du kan träna dina användare att återvinna Skype för företag regelbundet – eller åtminstone när det blir konstigt – kommer du förmodligen att ha mycket färre supportsamtal och många fler nöjda användare.