Il grande mistero della memoria Skype for Business
Questo articolo è stato scritto da Kenn Guilstorf, Skype for Business Escalation Engineer.
In qualità di ingegnere dell'escalation, assisto i clienti con alcuni dei problemi più "persnickety" Skype for Business. Ultimamente, ho ricevuto alcuni casi che sono "basati sulle prestazioni" - fondamentalmente, lamentele che Skype for Business è lento o lento, non consentirà la condivisione delle applicazioni o sta semplicemente usando troppa memoria. Molte volte, un'analisi di questi casi mostra che l'utente ha lasciato eseguire Skype for Business per settimane e, nel tempo, la memoria si è insinuata fino a quando non influisce sulle prestazioni. L'ho anche notato io stesso quando ho lasciato correre Skype per molto tempo. Quindi, cosa sta facendo Skype, e perché tiene così tanta memoria? (Ecco un piccolo suggerimento: questo è normale e per progettazione. Non c'è niente di male: qualsiasi programma nativo viene eseguito in questo.)
Quanta memoria può masticare?
Il primo passaggio per risolvere qualsiasi problema consiste nel comprendere il problema e il primo passaggio per comprendere qualsiasi problema consiste nel definirlo. Questo non è così facile da fare come sembra.
Quando si avvia per la prima volta Skype for Business (SfB), l'utilizzo della memoria è comparabilmente ridotto (se è possibile contare 100 MB come piccoli). Questo problema si verifica in un numero qualsiasi di strumenti, ad esempio Gestione attività:
Figura 1: Non ingannare: Lync.exe è il nome del processo per SfB (versione a 32 bit)
Nel corso del tempo, la quantità di memoria usata dal processo aumenterà. La dimensione che cresce sarà determinata dalla quantità di Skype usata, da ciò per cui viene usato e così via. Ad esempio, ecco lo stesso client dopo circa 24 ore:
Figura 2: Lo stesso SfB 24 ore dopo
Quindi, Skype ha consumato circa 32 MB in 24 ore. Non è molto, giusto? In realtà non lo è - fino a quando non spiego che Skype era solo seduto inattivo per tutte quelle 24 ore. Fondamentalmente, ho iniziato a Skype for Business su un computer, l'ho bloccato e ho aspettato circa 24 ore prima di sbloccarlo. In uso, il pedaggio sarebbe stato molto più alto, soprattutto se partecipassi a riunioni, usassi la condivisione di app o desktop in tali riunioni, usassi la messaggistica istantanea e così via. Sono stati rilevati casi in cui Skype for Business utilizzo della memoria è cresciuto a 300-500 MB in un solo giorno. Le cose possono diventare rischiose dopo una o più settimane di utilizzo, soprattutto nel client a 32 bit molto più vincolato alla memoria.
Mostrami la memoria
Sono disponibili molti strumenti in grado di profilare la memoria. Uno dei più diffusi, almeno in Microsoft, è lo strumento SysInternals VMMap, disponibile in VMMap v3.26. È possibile usarlo per esaminare la memoria del processo e verificare se è possibile profilare la memoria Skype for Business.
Dopo aver scaricato VMMap, eseguirlo. All'inizio, verrà aperto un elenco di processi in modo da poter scegliere il processo che si vuole esaminare. Scegliere lync.exee fare clic su OK.
Figura 3: VMMap all'avvio
Verrà quindi visualizzato un elemento grafico che è una rappresentazione multicolore del profilo di memoria corrente per l'eseguibile selezionato, Lync.exe, in questo caso.
Figura 4: Inizio di VMMap per Lync.exe avviate di recente
Ci sono molte informazioni qui, e descrivendolo tutto riempirebbe uno o più post di blog a sé stante. Se siete interessati, ci sono diversi grandi libri e articoli online che possono aiutare a spiegarlo. (Personalmente, consiglio "Advanced Windows" di Jeffrey Richter - attualmente fuori stampa, ma ancora eccellente nello spiegare come funziona la memoria. Puoi trovarne copie usate nel tuo negozio di libri preferito.
Come si può vedere, la memoria mostrata in Gestione attività non è allineata ad alcuna categoria in VMMap. Gestione attività è una rappresentazione più generalizzata; è accurato, semplicemente non conta tutto. VMMap è molto più completo.
Ecco l'istanza di Skype dopo il periodo di attesa di 24 ore:
Figura 5: VMMap per Skype dopo 24 ore
Dov'è la memoria?
Se si confronta ogni singola categoria, nulla si mette davvero in riga. In realtà trovare ciò che sta consumando la memoria è difficile da fare perché le categorie di memoria fluttuano quando gli oggetti e le richieste di memoria vengono effettuate e rilasciate e la memoria viene riservata e di cui viene eseguito il commit per l'archiviazione di vari oggetti. Il "kernel di conoscenza" (ai fini di questo blog, comunque) è la categoria "Gratuito". Nell'esempio la memoria "libera" è tutto lo spazio disponibile "riservato" per l'eseguibile di Lync. In Gestione attività viene tuttavia visualizzato solo un determinato tipo di memoria con commit. La memoria riservata non viene conteggiata perché non è in uso.
Allora, dov'è la memoria? Questo diventa difficile da individuare perché la memoria non viene persa. Contrariamente alla credenza popolare, il team Skype non è stato sovvenzionato dai produttori di memoria desktop. Non esiste un tracciato nefasto per fare in modo che i clienti aggiornino i sistemi o la memoria. Questo non è nemmeno un caso di obsolescenza pianificata. La verità è un po' più difficile da spiegare.
Facciamo un passo indietro per rendere le cose più chiare. Quando si avvia per la prima volta il client Skype for Business, ha un footprint di memoria relativamente ridotto, in genere 100 MB, a seconda del numero di contatti di cui tenere traccia per conto dell'utente e di altri sovraccarichi (è possibile visualizzarlo chiaramente nei dati precedenti). Dopo alcuni giorni, si noterà che questo footprint cresce di diverse centinaia di migliaia di byte a diversi megabyte. In alcune situazioni, questo può essere un problema, ma non è necessariamente un problema in Skype for Business stesso. Si tratta piuttosto di un effetto del paradigma di programmazione windows e del modo in cui gestisce la memoria in modo nativo.
Programmazione di Windows cosa?
Darò solo una visualizzazione semplicistica della memoria di Windows qui. La memoria di Windows viene gestita tramite costose procedure (in termini di cicli e risorse del computer) note come allocazioni e deallocazioni. Quando un programma ha bisogno di memoria, chiede a Windows di allocarlo. Quando è tutto con la memoria, il programma chiede a Windows di deallocarlo. Internamente, Windows esegue diversi processi per gestire le richieste di memoria.
Quando viene effettuata una richiesta, Windows controlla la memoria di cui è già stato eseguito il commit nel processo, ma che il processo non usa. Windows sta cercando di vedere se è presente un blocco di memoria sufficientemente grande da usare. Se c'è, il sistema lo usa e va sulla sua strada allegra. In caso contrario, controlla la memoria riservata. Se è presente un blocco di memoria riservata sufficientemente grande, lo esegue il commit (in blocchi definiti dal sistema operativo noti come "pagine") e archivia la variabile al suo interno. È stato eseguito il commit della memoria ed è stato appena aumentato il footprint di memoria dell'eseguibile.
Cosa accade se la memoria riservata non è sufficiente per gestire la richiesta? Il sistema operativo tenta di riservare più memoria, se possibile. Ecco dove entra in gioco la differenza tra l'architettura a 32 bit e l'architettura a 64 bit. Un processo a 32 bit può usare solo un massimo di 4 GB di memoria. Questo perché 4 GB è la quantità massima che un registro a 32 bit può risolvere. Un bit può contenere solo un file binario 1 o 0. Pertanto, 32 bit significa che 232 è l'indirizzo più alto consentito). Grazie all'architettura a 32 bit, solo circa 2 GB di tale memoria vengono assegnati al processo stesso, il resto usato dal sistema operativo per eseguire il mapping delle DLL comuni, occuparsi degli oggetti comuni in modalità kernel e così via. In un sistema a 64 bit, i registri lunghi a 64 bit possono gestire 264, ovvero circa 18 exabyte. Tuttavia, Windows limita artificialmente la quantità di memoria disponibile per essere riservata tra 2 terabyte e 4 terabyte (TB), a seconda della versione di Windows.
Una volta riservata, la memoria verrà sottoposta a commit e quindi usata come prima. Il processo di deallocazione è in gran parte inverso, ad eccezione di uno o due dettagli piccoli ma importanti.
In primo luogo, se non richiesto, Windows non "cancella" mai la memoria. Quando la memoria viene deallocata, viene contrassegnata come libera nella mappa di memoria di Windows. Tutto ciò che ha tenuto è ancora lì e rimarrà lì fino a quando non viene sovrascritto da un'altra allocazione. In seguito, Windows raramente esegue il de-commit della memoria, a meno che non sia richiesto di eseguire questa operazione. Come ho detto in precedenza, le operazioni di memoria sono piuttosto costose per le risorse. Quindi, se un programma aveva bisogno della memoria allocata in precedenza, Windows presuppone che potrebbe aver bisogno di quella memoria di nuovo e trattenerà il de-commit della memoria fino a quando non deve assolutamente farlo. Infine, Windows non "unisce" mai la memoria. Ciò significa che la memoria liberata da Windows non viene mai "aggregata" e i blocchi di memoria libera non vengono mai "spostati insieme" per creare blocchi più grandi di memoria libera. Tutte queste funzioni sono raggruppate in una categoria nota come "Garbage Collection". .NET Framework include alcune funzionalità di Garbage Collection. Tuttavia, Skype for Business è un'applicazione "nativa" o non-.NET).
Skype for Business elabora molti oggetti ogni secondo di dimensioni variabili. Deve farlo per essere lo strumento straordinario che vogliamo che sia. Viene chiesto di gestire i contatti, gestire calendari (riunioni), messaggistica istantanea con amici, parenti e colleghi e persino parlare con loro usando sia voce che video, condividere desktop o finestre e così via. Beh, per citare il compianto, grande Robert Heinlein, tra gli altri: "Non c'è una cosa come un pranzo libero."
La gestione di così tanti oggetti di dimensioni così diverse e spesso variabili crea allocazioni e allocazioni di blocchi di memoria di dimensioni variabili. Nel corso del tempo, questo causa la frammentazione della memoria, a volte grave, che aumenta il footprint di memoria di Skype for Business.
Un esempio potrebbe illustrare meglio questo punto. Si supponga che Skype (o qualsiasi programma nativo, in realtà) alloca 64 oggetti, numerato da 1 a 64, che sono 4 K byte ciascuno di dimensioni:
Figura 6: 64 oggetti, ognuno con 4 KB di memoria
Ciò causa un impegno e un'allocazione di memoria di 256 KB. Si supponga ora che il programma non richieda gli oggetti con numerazione pari, quindi li rilascia:
Figura 7: Il rilascio di tutti gli oggetti con numerazione pari libera 128 KB di memoria.
Se si esamina l'immagine più ampia della memoria complessiva (usando VMMap o uno strumento simile), si noterà che una delle colonne di cui è stato eseguito il commit (probabilmente nella sezione Heap , ma dipende esattamente dal modo in cui il programma ha richiesto la memoria) ha 128 KB in meno e la sezione Gratuita è cresciuta di 128 KB. In Gestione attività il programma possiede ora solo 128 KB di memoria.
Si supponga quindi che il programma abbia un singolo oggetto da 8 KB che deve archiviare. Questo dovrebbe essere semplice. Dopo tutto, ha 128 KB gratuiti. Tuttavia, il tentativo di archiviare tale oggetto da 8 KB creerà una nuova prenotazione di memoria anziché archiviare la memoria nello spazio disponibile di 128 KB. Questo perché, se si guarda la memoria, si può vedere che è ancora segmentato in blocchi da 4 KB! Windows non ha un blocco di memoria sufficiente per contenere l'oggetto da 8 KB, quindi deve riservare ed eseguire il commit di più memoria nel programma.
Questo è un esempio piuttosto intriso, ma illustra la difficoltà della gestione della memoria di Skype. Skype gestisce un numero elevato di oggetti che non hanno dimensioni facilmente definibili. Questi oggetti sono tutti di lunghezza variabile. Ciò significa che quando gli oggetti vengono archiviati e liberati, soprattutto per un lungo periodo di tempo, ad esempio giorni o settimane, la frammentazione della memoria può diventare grave e, poiché Windows deve allocare più memoria per archiviare i nuovi oggetti, il footprint di memoria aumenta eccessivamente.
Quando questo causa problemi nel client a 32 bit, è spesso consigliabile passare al client a 64 bit perché la memoria è molto meno vincolata, grazie all'architettura a 64 bit rispetto a 32 bit. Tuttavia, l'eccessiva crescita della memoria, tra le altre considerazioni, può causare lentezza anche nel client a 64 bit. Queste altre considerazioni includono memoria di sistema complessiva, velocità del disco (perché la memoria del programma è in genere supportata da memoria virtuale nel file di paging di Windows), quante altre applicazioni sono aperte e così via. In entrambi i casi, man mano che il footprint di memoria Skype for Business cresce nel tempo, peggio sarà. Nel caso del client a 32 bit, ciò può causare lo spazio esaurito degli oggetti più grandi richiesti da Skype, ad esempio il buffer interno per la condivisione delle applicazioni, e causare errori.
Ad essere onesti, la memoria è solo una risorsa usata nel tempo, ma è la più ovvia. L'utilizzo degli handle può aumentare, i thread aumenteranno nel tempo, la memoria del pool di paging aumenterà e così via. Ognuno di questi aumenti può avere un impatto sul processo e, in alcuni casi, sull'intero sistema operativo. Questo è uno dei tanti motivi per cui suggeriamo , anche per il client a 64 bit, che gli utenti escano e riavvino Skype ogni giorno (o, almeno, settimanale) come procedura consigliata.
Cosa devo fare a riguardo e posso forzare il riavvio di Skype?
Esistono diversi modi per forzare il riavvio di Skype, ma non esiste un unico modo migliore. Un modo, naturalmente, è l'educazione degli utenti. Gli utenti sono gli arbitri dell'utilizzo del desktop nella maggior parte dei casi, quindi è pragmatico insegnare loro a disconnettersi e chiudere Skype quando partono per la giornata. Questa operazione può essere eseguita anche come passaggio obbligatorio scrivendo uno script personalizzato o un eseguibile e quindi eseguendo uno come attività dell'Utilità di pianificazione. Questo approccio è un po 'pugno ham, e può causare Skype a ciclo anche quando è "in uso" (anche se questo può essere attenuato in qualche modo attraverso le condizioni dell'utilità di pianificazione). Ci sono anche opportunità di terze parti per la gestione di desktop e computer, potenziali opzioni BIOS e così via.
La linea di fondo è che è meglio per Skype for Business ciclo giornaliero - o, almeno, settimanale. Se è possibile eseguire regolarmente il training degli utenti per riciclare Skype for Business o, almeno, quando le cose si fanno strane, è probabile che si abbiano molte meno chiamate helpdesk e molti più utenti felici.