A nagy Skype Vállalati verzió memória rejtély

• A következőre érvényes::

  Skype for Business

Ezt a cikket Kenn Guilstorf, Skype Vállalati verzió eszkalációs mérnök írta.

Eszkalációs mérnökként segítem az ügyfeleket a több "persnickety" Skype Vállalati verzió problémákban. Mostanában számos olyan esetet kaptam, amelyek "teljesítményalapúak" – alapvetően olyan panaszok, amelyek Skype Vállalati verzió lassúak vagy lassúak, nem engedélyezik az alkalmazásmegosztást, vagy egyszerűen túl sok memóriát használnak. Az ilyen esetek vizsgálata sokszor azt mutatja, hogy a felhasználó hetekig engedélyezte Skype Vállalati verzió futtatását, és idővel a memória fel nem gyűrődött, amíg az nem befolyásolja a teljesítményt. Magam is észrevettem, amikor hosszú ideig hagytam futni a Skype-ot. Szóval, mit csinál a Skype, és miért tart annyi memóriát? (Íme egy kis tipp: Ez normális és szándékos. Semmi sem baj – minden natív program belefut ebbe.)

Mennyi memóriát tud átrágni?

A probléma megoldásának első lépése a probléma megértése, a probléma megértésének első lépése pedig annak meghatározása. Ez nem olyan egyszerű, mint amilyennek hangzik.

A Skype Vállalati verzió (SfB) első indításakor a memóriahasználat összehasonlíthatóan kicsi (ha 100 MB-ot meg tud számolni kicsiként). Ez számos eszközben, például a Feladatkezelőben is megjelenik:

1. ábra: Ne tévesszen meg: Lync.exe az SfB folyamatneve (32 bites verzió)

Idővel a folyamat által felhasznált memória mennyisége nőni fog. A méretet az határozza meg, hogy mennyi Skype-ot használnak, mire használják, és így tovább. Íme például ugyanaz az ügyfél körülbelül 24 óra elteltével:

2. ábra: Ugyanaz az SfB 24 órával később

A Skype tehát körülbelül 32 MB-ot fogyasztott 24 óra alatt. Ez nem sok, ugye? Ez tényleg nem - amíg el nem magyarázom, hogy a Skype csak tétlenül ült mind a 24 órán át. Alapvetően, elkezdtem Skype Vállalati verzió egy számítógépen, zároltam, és vártam körülbelül 24 órát, mielőtt kinyitom. Használat esetén az útdíj sokkal magasabb lett volna – különösen akkor, ha bekapcsolódtam az értekezletekbe, alkalmazásmegosztást vagy asztalmegosztást használtam az értekezleteken, csevegőt használtam stb. Láttam olyan eseteket, amikor Skype Vállalati verzió memóriahasználat 300–500 MB-ra nőtt egyetlen nap alatt. A dolgok egy vagy több hét használat után is elkeskenyedhetnek – különösen a sokkal több memóriakorlátozott 32 bites ügyfélen.

A memória megjelenítése

Számos eszköz képes profilkészítésre a memóriáról. Az egyik legnépszerűbb – legalábbis a Microsoftnál – a SysInternals eszköz virtuálisgép-térképe, amely a VMMap 3.26-os verziójában érhető el. A használatával megvizsgálhatjuk a folyamat memóriáját, és megállapíthatjuk, hogy profilt tudunk-e adni a Skype Vállalati verzió memóriáról.

A VMMap letöltése után futtassa. A folyamat indításakor megnyílik egy folyamatlista, amelyből kiválaszthatja a megvizsgálni kívánt folyamatot. Kiválasztom lync.exe , és az OK gombra kattintok.

3. ábra: Virtuálisgép-térkép a kezdőképernyőn

Ezután megjelenik egy ábra, amely a kijelölt végrehajtható fájl aktuális memóriaprofiljának többszínű ábrázolása – ebben az esetben Lync.exe.

4. ábra: A nemrég elindított virtuálisgép-térkép indítása Lync.exe

Sok információ van itt, és leírja, hogy minden lenne kitölteni egy vagy több blogbejegyzést a saját. Ha érdekli, számos nagyszerű könyvet és online cikket, amelyek segíthetnek elmagyarázni. (Személy szerint azt javaslom, "Advanced Windows" Jeffrey Richter - jelenleg nem nyomtatható, de még mindig kiváló magyarázó, hogyan működik a memória. A használt példányokat a kedvenc könyvesboltjában találja.)

Mint látható, a Feladatkezelőben látható memória nem felel meg a VMMap egyik kategóriájának sem. A Feladatkezelő egy általánosabb reprezentáció; Pontos, csak nem számít mindent. A VMMap sokkal átfogóbb.

Íme a Skype-példány a 24 órás várakozási idő után:

5. ábra: Virtuálisgép-térkép a Skype-hoz 24 óra elteltével

Hol van a memória?

Ha összehasonlítja az egyes kategóriákat, semmi sem áll össze. Valójában nehéz megtalálni, hogy mi fogyasztja a memóriát, mert a memória kategóriái ingadoznak az objektumok és memóriakérések során, és a memória le van foglalva és le van foglalva a különböző objektumok tárolásához. A "kernel a tudás" (szempontjából ezt a blogot, egyébként) a "Szabad" kategória. A példánkban a "szabad" memória a Lync végrehajtható fájlhoz "lefoglalt" terület. A Feladatkezelőben azonban csak bizonyos típusú "véglegesített" memória jelenik meg. A fenntartott memória nem számít bele, mert nincs használatban.

Hol van a memória? Ezt nehéz megállapítani, mert a memória nem vész el. A közhiedelemmel ellentétben a Skype-csapatot nem támogatták az asztali memóriagyártók. Az ügyfeleknek nem áll rendelkezésre olyan hírhedt terv, amely lehetővé szeretné tenni, hogy az ügyfelek frissíthessenek rendszereket vagy memóriát. Ez nem is egy tervezett elavulás. Az igazságot egy kicsit nehezebb elmagyarázni.

Térjünk vissza egy kicsit, hogy egyértelműbbé tegyük a dolgokat. Az Skype Vállalati verzió-ügyfél első indításakor viszonylag kis memóriaigényű – általában 100 MB-os vagy annál nagyobb – attól függően, hogy hány névjegyet tart nyilván ön helyett, illetve egyéb többletterhelést (ezt a fenti adatokban egyértelműen láthatja). Néhány nap elteltével megfigyelheti, hogy ez a lábnyom több százezer bájtról több megabájtra nő. Bizonyos helyzetekben ez problémát jelenthet , de nem feltétlenül önmagában Skype Vállalati verzió. Ez inkább a Windows programozási paradigma egyik hatása, és azt, hogy hogyan kezeli natív módon a memóriát.

Mi a windowsos programozás?

Itt csak egyszerű képet adok a Windows memóriáról. A Windows-memóriát költséges (számítógépes ciklusok és erőforrások szempontjából) eljárások, más néven foglalások és lefoglalások kezelik. Ha egy programnak memóriára van szüksége, arra kéri a Windowst, hogy foglalja le. Ha a memóriával van, a program kéri a Windowst a lefoglalás megszüntetésére. A Windows belsőleg számos folyamaton megy keresztül a memóriakérelmek kezeléséhez.

Amikor kérést küld, a Windows ellenőrzi a memóriát, amelyet már véglegesített a folyamathoz, de a folyamat nem használ. A Windows azt szeretné tudni, hogy van-e elég nagy memóriablokk a használathoz. Ha van, a rendszer használja, és megy a boldog utat. Ha nincs, akkor ellenőrzi a fenntartott memóriát. Ha elég nagy a fenntartott memóriablokk, véglegesíti azt (az operációs rendszer által definiált adattömbökben, más néven "lapokban"), és tárolja benne a változót. A memória véglegesítése megtörtént, és most fejlődött a végrehajtható fájl memóriaigénye.

Mi történik, ha nincs elegendő fenntartott memória a kérés kezeléséhez? Az operációs rendszer több memóriát próbál lefoglalni – ha tud. Itt jelenik meg a különbség a 32 bites és a 64 bites architektúra között. A 32 bites folyamatok legfeljebb 4 GB memóriát használhatnak. Ennek az az oka, hogy a 4 GB az a maximális összeg, amelyet egy 32 bites regiszter kezelni tud. (Egy bit csak 1 vagy 0 – bináris fájlt tartalmazhat. Ezért a 32 bit azt jelenti, hogy a 2³² az engedélyezett legmagasabb cím). A 32 bites architektúrának köszönhetően a rendszer csak körülbelül 2 GB memóriát rendel magához a folyamathoz, a többit az operációs rendszer a közös DLL-ek leképezésére, a közös kernelmódú objektumok kezelésére stb. használja. A 64 bites rendszerekben a 64 bites regiszterek^264-et képesek kezelni, ami körülbelül 18 exabájt. A Windows azonban a Windows verziójától függően mesterségesen korlátozza a lefoglalható memória mennyiségét 2 terabájt és 4 terabájt (TB) között.

A lefoglalt memóriát a rendszer véglegesíteni fogja, majd a korábbiakhoz hasonlóan fogja használni. A felosztás megszüntetése nagyrészt fordított – kivéve egy vagy két apró, de fontos részletet.

Először is, hacsak nem kéri, a Windows soha nem "törli" a memóriát. A memória felszabadításakor a rendszer szabadként jelöli meg a Windows memóriatérképén. Bármi is legyen, az még mindig ott van, és ott marad, amíg egy másik foglalás felülírja. Ezután a Windows ritkán törli a memória véglegesítését, hacsak erre nincs szükség. Ahogy korábban említettem, a memóriaműveletek meglehetősen erőforrás-költségesek. Tehát ha egy programnak szüksége van a korábban lefoglalt memóriára, a Windows feltételezi, hogy újra szüksége lehet erre a memóriára, és visszatartja a memória véglegesítésének megszüntetését, amíg egyáltalán nem kell. Végül a Windows soha nem "olvasztja" a memóriát. Ez azt jelenti, hogy a Windows által felszabadított memória soha nem lesz "összesítve", és a szabad memóriablokkok soha nem lesznek "együtt mozgatva", hogy nagyobb szabad memóriablokkok legyenek. (Ezeket a függvényeket a rendszer egy "szemétgyűjtés" néven ismert kategóriába sorolja. .NET-keretrendszer híresen rendelkezik néhány szemétgyűjtési funkcióval. A Skype Vállalati verzió azonban "natív" vagy non-.NET alkalmazás.)

Skype Vállalati verzió másodpercenként számos, változó méretű objektumot dolgoz fel. Ezt azért kell tennie, hogy a lenyűgöző eszköz legyen, amilyennek szeretnénk. Megkérjük, hogy kezelje a névjegyeket, kezelje a naptárakat (értekezleteket), csevegjen barátaival, rokonaival és munkatársaival, és akár hanggal és videóval is beszéljen velük, ossza meg az asztalokat vagy az ablakokat stb. Nos, idézem a késői, nagy Robert Heinlein, többek között: "Nincs olyan dolog, mint egy ingyenes ebéd."

Az ilyen eltérő és gyakran változó méretű objektumok kezelése a memória változó méretű adattömbjeinek lefoglalását és lefoglalásának megszüntetését eredményezi. Idővel ez memóriatöredezettséget okoz – időnként súlyos – ami növeli a Skype Vállalati verzió memóriaigényét.

Egy példa jobban szemléltetheti ezt a pontot. Tegyük fel, hogy a Skype (vagy bármely natív program) 64 objektumot foglal le 1–64 számmal, amelyek egyenként 4 K bájt méretűek:

6. ábra: 64 objektum, mindegyik 4 KB memóriát használ

Ez 256 KB-os memóriafoglalást és kötelezettségvállalást eredményez. Most tegyük fel, hogy a programnak nincs szüksége a páros számú objektumokra, ezért felszabadítja őket:

7. ábra: Az összes páros számú objektum felszabadítása 128 KB memóriát szabadít fel!

Ha a teljes memória nagyobb képét látja (VMMap vagy hasonló eszköz használatával), láthatja, hogy az egyik véglegesített oszlop (valószínűleg a Halom szakaszban, de pontosan attól függ, hogy a program hogyan kérte le a memóriát) 128 KB-kal kevesebb, az Ingyenes szakasz pedig 128 KB-kal nőtt. A Feladatkezelőben a program már csak 128 KB memóriával rendelkezik.

Tegyük fel, hogy a programnak egyetlen 8 KB-os objektumot kell tárolnia. Ennek egyszerűnek kell lennie. Végül is 128 KB ingyenes. A 8 KB-os objektum tárolása azonban új memóriafoglalást hoz létre ahelyett, hogy a memóriát a 128 KB-os szabad helyen tárolná. Ennek az az oka, hogy ha megtekinti a memóriát, láthatja, hogy még mindig 4 KB-os adattömbökre van szegmentált. A Windows nem rendelkezik elég nagy memóriablokkmal a 8 KB-os objektum tárolásához, ezért több memóriát kell lefoglalnia és lefoglalnia a programnak.

Ez egy meglehetősen ellentmondásos példa, de bemutatja a Skype memóriakezelésének nehézségét. A Skype számos olyan objektumot kezel, amelyek mérete nem határozható meg könnyen. Ezek az objektumok mind változékonyan hosszúak. Ez azt jelenti, hogy mivel az objektumok tárolása és felszabadítása – különösen hosszú ideig, például napok vagy hetek alatt – a memória töredezettsége súlyossá válhat, és mivel a Windowsnak több memóriát kell lefoglalnia az új objektumok tárolásához, a memóriaigény túlzottan nő.

Ha ez problémákat okoz a 32 bites ügyfélben, gyakran javasoljuk a 64 bites ügyfélre való áttérést, mivel a 64 bites és a 32 bites architektúra miatt a memória sokkal kevésbé korlátozott. A túlzott memórianövekedés azonban – egyéb szempontok mellett – lassúságot okozhat még a 64 bites ügyfélben is. Ezen egyéb szempontok közé tartozik a teljes rendszermemória, a lemezsebesség (mivel a programmemória általában a Windows lapozófájlban lévő virtuális memóriával van alátámasztva), hogy hány más alkalmazás van megnyitva stb. Mindkét esetben, ahogy a Skype Vállalati verzió memóriaigény idővel növekszik, annál rosszabbul fog teljesíteni. A 32 bites ügyfél esetén ez azt okozhatja, hogy a Skype által igényelt nagyobb objektumok – például az alkalmazásmegosztás belső puffere – elfogynak a tárhelyek, és hibákat okoznak.

A méltányosság kedvéért a memória csak egy erőforrás, amelyet az idő múlásával fogyasztanak – de ez a legnyilvánvalóbb. A használat kezelése nőhet, a szálak idővel növekedni fognak, a lapszámozott készlet memóriája is nőni fog stb. A növekedések mindegyike hatással lehet a folyamatra és bizonyos esetekben a teljes operációs rendszerre. Ez az egyik számtalan oka annak, hogy ajánlott eljárásként azt javasoljuk – még a 64 bites ügyfél esetében is –, hogy a felhasználók naponta (vagy legalább hetente) kilépnek és újraindítják a Skype-ot.

Mit tegyek ezzel kapcsolatban, és kényszeríthetem a Skype újraindítását?

A Skype újraindítását többféleképpen is kényszerítheti, de nincs egyetlen, legjobb módszer. Az egyik módszer természetesen a felhasználói oktatás. A legtöbb esetben a felhasználók jelentik az asztali használatot, ezért gyakorlatias, ha arra tanítják őket, hogy jelentkezzenek ki és zárják be a Skype-ot, amikor elhagyják az adott napot. Ez kötelező lépésként is elvégezhető egy egyéni szkript vagy végrehajtható fájl megírásával, majd a feladatütemező feladatként való futtatásával. Ez a megközelítés kissé ham-fisted, és okozhatJa a Skype ciklus akkor is, ha az "használatban" (bár ez lehet enyhíteni valamivel keresztül Feladatütemező feltételek). Léteznek külső felektől származó lehetőségek az asztali és számítógép-kezelésre, a BIOS lehetséges lehetőségeire és így tovább.

A lényeg az, hogy a legjobb, ha Skype Vállalati verzió naponta vagy legalább hetente vált. Ha rendszeresen betaníthatja a felhasználókat a Skype Vállalati verzió újrahasznosítására – vagy legalábbis, ha furcsa dolgok történnek –, valószínűleg sokkal kevesebb ügyfélszolgálati hívása és még sok boldog felhasználója lesz.