Le grand mystère de la mémoire Skype Entreprise
Cet article a été écrit par Kenn Guilstorf, ingénieur Skype Entreprise escalade.
En tant qu’ingénieur d’escalade, j’aide les clients à résoudre certains des problèmes de Skype Entreprise les plus « persnickety ». Dernièrement, j’ai reçu un certain nombre de cas qui sont « basés sur les performances » - en gros, des plaintes qui Skype Entreprise est lente ou lente, n’autorise pas le partage d’application, ou utilise simplement trop de mémoire. Souvent, une enquête sur ces cas montre que l’utilisateur a laissé Skype Entreprise s’exécuter pendant des semaines et, au fil du temps, la mémoire s’est cressée jusqu’à ce qu’elle affecte les performances. Je l’ai même remarqué moi-même quand j’ai laissé Skype s’exécuter pendant longtemps. Alors, que fait Skype, et pourquoi est-ce qu’il contient tant de mémoire ? (Voici un petit conseil : c’est normal et par conception. Rien n’est mal : tous les programmes natifs se heurtent à cela.)
Quelle quantité de mémoire peut-il mâcher ?
La première étape pour résoudre un problème consiste à comprendre le problème, et la première étape pour comprendre tout problème consiste à le définir. Ce n’est pas aussi facile à faire qu’il y paraît.
Lorsque Skype Entreprise (SfB) démarre pour la première fois, l’utilisation de la mémoire est relativement faible (si vous pouvez compter 100 Mo). Nous pouvons voir que cela se produit dans un certain nombre d’outils, tels que le Gestionnaire des tâches :
Figure 1 : Ne vous y trompez pas : Lync.exe est le nom du processus pour SfB (version 32 bits)
Au fil du temps, la quantité de mémoire utilisée par le processus va augmenter. Sa taille sera déterminée par la quantité de Skype utilisée, son utilisation, etc. Par exemple, voici ce même client après environ 24 heures :
Figure 2 : Le même SfB 24 heures plus tard
Skype a donc consommé environ 32 Mo en 24 heures. C’est pas grand-chose, hein ? Ce n’est vraiment pas - jusqu’à ce que j’explique que Skype était juste resté inactif pendant toutes ces 24 heures. Fondamentalement, j’ai commencé Skype Entreprise sur un ordinateur, verrouillé, et j’ai attendu environ 24 heures avant de le déverrouiller. Lors de l’utilisation, le tarif aurait été beaucoup plus élevé, en particulier si j’ai rejoint des réunions, utilisé le partage d’applications ou le partage de bureau dans ces réunions, utilisé la messagerie instantanée, etc. J’ai vu des cas où Skype Entreprise utilisation de la mémoire est passée à 300-500 Mo en une seule journée. Les choses peuvent devenir désétent après une ou plusieurs semaines d’utilisation, en particulier sur le client 32 bits beaucoup plus limité en mémoire.
Montre-moi la mémoire
De nombreux outils peuvent profiler la mémoire. L’outil SysInternals VMMap, disponible sur VMMap v3.26, est l’un des plus populaires, du moins chez Microsoft. Nous pouvons l’utiliser pour examiner la mémoire du processus et voir si nous pouvons profiler la mémoire Skype Entreprise.
Une fois que vous avez téléchargé VMMap, exécutez-le. Au démarrage, une liste de processus s’ouvre afin que vous puissiez choisir le processus que vous souhaitez examiner. Je vais choisir lync.exe et cliquer sur OK.
Figure 3 : VMMap au démarrage
Ensuite, vous voyez un graphique qui est une représentation multicolore du profil de mémoire actuel pour l’exécutable que vous avez sélectionné , Lync.exe, dans ce cas.
Figure 4 : Démarrage de VMMap pour les Lync.exe récemment démarrées
Il y a beaucoup d’informations ici, et la description de tout cela remplirait un ou plusieurs billets de blog de son propre. Si vous êtes intéressé, il existe plusieurs excellents livres et articles en ligne qui peuvent vous aider à l’expliquer. (Personnellement, je recommande « Advanced Windows » de Jeffrey Richter – actuellement en panne d’impression, mais toujours excellent dans l’explication du fonctionnement de la mémoire. Vous pouvez trouver des copies d’occasion de celui-ci dans votre librairie préférée.)
Comme vous pouvez le voir, la mémoire affichée dans le Gestionnaire des tâches ne s’aligne sur aucune catégorie dans VMMap. Le Gestionnaire des tâches est une représentation plus généralisée ; c’est précis, ça ne compte pas tout. VMMap est beaucoup plus complet.
Voici notre instance Skype après la période d’attente de 24 heures :
Figure 5 : VMMap pour Skype après 24 heures
Où est la mémoire ?
Si vous comparez chaque catégorie individuelle, rien ne s’aligne vraiment. En fait, il est difficile de trouver ce qui consomme la mémoire, car les catégories de mémoire fluctuent à mesure que les objets et les demandes de mémoire sont effectués et libérés, et que la mémoire est réservée et validée pour le stockage de différents objets. Le « noyau de connaissances » (pour les besoins de ce blog, de toute façon) est la catégorie « Gratuit ». Dans notre exemple, la mémoire « libre » est tout l’espace disponible qui est « réservé » pour l’exécutable Lync. Mais seul un certain type de mémoire « validée » est affiché dans le Gestionnaire des tâches. La mémoire réservée n’est pas comptabilisée, car elle n’est pas utilisée.
Alors, où est la mémoire ? Cela devient difficile à identifier, car la mémoire n’est pas perdue. Contrairement à la croyance populaire, l’équipe Skype n’a pas été subventionnée par les fabricants de mémoire de bureau. Il n’existe aucun tracé malveillant pour amener les clients à mettre à niveau tous les systèmes ou la mémoire. Il ne s’agit même pas d’un cas d’obsolescence planifiée. La vérité est un peu plus difficile à expliquer.
Revenons un peu en arrière pour clarifier les choses. Lorsque vous démarrez le client Skype Entreprise pour la première fois, il a un encombrement mémoire relativement faible( généralement 100 Mo ou environ, en fonction du nombre de contacts dont il effectue le suivi pour vous et d’autres surcharges (vous pouvez le voir clairement dans les données ci-dessus). Après quelques jours, vous remarquerez que cette empreinte augmente de plusieurs centaines de milliers d’octets à plusieurs mégaoctets. Dans certaines situations, cela peut être un problème, mais ce n’est pas nécessairement un problème dans Skype Entreprise lui-même. Il s’agit plutôt d’un effet du paradigme de programmation Windows et de la façon dont il gère la mémoire en mode natif.
Programmation Windows quoi ?
Je vais seulement donner une vue simpliste de la mémoire Windows ici. La mémoire Windows est gérée par le biais de procédures coûteuses (en termes de cycles et de ressources informatiques) appelées allocations et désallocations. Lorsqu’un programme a besoin de mémoire, il demande à Windows de l’allouer. Une fois la mémoire terminée, le programme demande à Windows de la désallouer. En interne, Windows passe par plusieurs processus pour gérer les demandes de mémoire.
Lorsqu’une requête est effectuée, Windows vérifie la mémoire qu’il a déjà validée dans le processus, mais que le processus n’utilise pas. Windows cherche à voir s’il existe un bloc de mémoire suffisamment grand à utiliser. Si c’est le cas, le système l’utilise et continue son chemin joyeux. Si ce n’est pas le cas, il vérifie la mémoire réservée. S’il existe un bloc de mémoire réservé suffisamment grand, il le valide (dans les blocs définis par le système d’exploitation appelés « pages ») et y stocke la variable. La mémoire est maintenant validée, et nous venons d’ajouter l’empreinte mémoire de l’exécutable.
Que se passe-t-il s’il n’y a pas assez de mémoire réservée pour gérer la requête ? Le système d’exploitation tente de réserver davantage de mémoire, s’il le peut. Voici où la différence entre l’architecture 32 bits et l’architecture 64 bits entre en jeu. Un processus 32 bits ne peut utiliser que 4 Go de mémoire au maximum. Cela est dû au fait que 4 Go est la quantité maximale qu’un registre 32 bits peut traiter. (Un bit ne peut contenir que 1 ou 0 – binaire. Par conséquent, 32 bits signifie que 232 est l’adresse la plus élevée autorisée). Grâce à l’architecture 32 bits, seulement 2 Go environ de cette mémoire sont affectés au processus lui-même, le reste étant utilisé par le système d’exploitation pour mapper les DLL courantes, prendre en charge les objets courants en mode noyau, etc. Dans un système 64 bits, les registres longs 64 bits peuvent gérer 264, ce qui s’avère être d’environ 18 exaoctets. Toutefois, Windows limite artificiellement la quantité de mémoire disponible pour être réservée à entre 2 téraoctets et 4 téraoctets (To), selon la version de Windows.
Une fois la mémoire réservée, elle est validée, puis utilisée comme précédemment. Le processus de désallocation est en grande partie l’inverse, à l’exception d’un ou deux détails petits mais importants.
Tout d’abord, à moins que cela ne soit demandé, Windows ne « efface » jamais la mémoire. Lorsque la mémoire est désallouée, elle est marquée comme libre dans la carte de mémoire Windows. Tout ce qu’il détient est toujours là et y restera jusqu’à ce qu’il soit remplacé par une autre allocation. Ensuite, Windows annule rarement la validation de la mémoire, sauf si vous y êtes invité. Comme je l’ai dit précédemment, les opérations de mémoire sont assez coûteuses en ressources. Par conséquent, si un programme avait besoin de la mémoire allouée précédemment, Windows suppose qu’il peut avoir besoin de cette mémoire à nouveau et qu’il va différer la désactivation de la mémoire jusqu’à ce qu’elle soit absolument nécessaire. Enfin, Windows ne « fusionne » jamais la mémoire. Cela signifie que la mémoire libérée par Windows n’est jamais « agrégée » et que les blocs de mémoire libre ne sont jamais « déplacés ensemble » pour créer des blocs de mémoire libre plus volumineux. (Toutes ces fonctions sont regroupées dans une catégorie connue sous le nom de « garbage collection ». Le .NET Framework dispose de certaines fonctionnalités de garbage collection. Toutefois, Skype Entreprise est une application « native » ou non-.NET.)
Skype Entreprise traite chaque seconde de nombreux objets de taille variable. Il doit le faire pour être l’outil étonnant que nous voulons qu’il soit. Nous lui demandons de gérer les contacts, de gérer les calendriers (réunions), la messagerie instantanée avec nos amis, parents et collègues, et même de leur parler à l’aide de la voix et de la vidéo, de partager des ordinateurs de bureau ou des fenêtres, etc. Eh bien, pour citer le regretté, le grand Robert Heinlein, entre autres : « Il n’y a pas une telle chose comme un déjeuner gratuit. »
La gestion d’un si grand nombre d’objets de tailles différentes et souvent variables crée des allocations et des désallocations de blocs de mémoire de taille variable. Au fil du temps, cela entraîne une fragmentation de la mémoire ( parfois grave) qui augmente l’empreinte mémoire de Skype Entreprise.
Un exemple pourrait mieux illustrer ce point. Supposons que Skype (ou n’importe quel programme natif, en fait) alloue 64 objets, numérotés de 1 à 64, qui ont chacun une taille de 4 000 octets :
Figure 6 : 64 objets, chacun utilisant 4 Ko de mémoire
Cela entraîne une allocation et un engagement de mémoire de 256 Ko. À présent, supposons que le programme ne nécessite pas les objets paires, il les libère :
Figure 7 : La libération de tous les objets paires libère 128 Ko de mémoire !
Si vous examinez la vue d’ensemble de la mémoire globale (à l’aide de VMMap ou d’un outil similaire), vous verrez que l’une des colonnes validées (probablement dans la section Tas , mais cela dépend exactement de la façon dont le programme a demandé la mémoire) a 128 Ko de moins, et la section Gratuit a augmenté de 128 Ko. Dans le Gestionnaire des tâches, le programme ne possède désormais que 128 Ko d’octets de mémoire.
Supposons ensuite que notre programme dispose d’un seul objet de 8 Ko qu’il doit stocker. Cela devrait être simple. Après tout, il a 128 Ko gratuit. Toutefois, la tentative de stockage de cet objet de 8 Ko crée une nouvelle réservation de mémoire au lieu de stocker la mémoire dans l’espace libre de 128 Ko. En effet, si vous examinez la mémoire, vous pouvez voir qu’elle est toujours segmentée en blocs de 4 Ko ! Windows ne dispose pas d’un bloc de mémoire suffisamment grand pour contenir l’objet de 8 Ko. Il doit donc réserver et valider davantage de mémoire dans le programme.
Il s’agit d’un exemple plutôt fictif, mais il illustre la difficulté de la gestion de la mémoire de Skype. Skype gère un grand nombre d’objets qui n’ont pas une taille facilement définissable. Ces objets sont tous de longueur variable. Cela signifie qu’à mesure que les objets sont stockés et libérés, en particulier sur une longue période de temps, comme des jours ou des semaines, la fragmentation de la mémoire peut devenir grave et, comme Windows doit allouer plus de mémoire pour stocker les nouveaux objets, l’empreinte mémoire augmente de façon excessive.
Lorsque cela provoque des problèmes dans le client 32 bits, nous vous suggérons souvent de passer au client 64 bits, car la mémoire y est beaucoup moins limitée, grâce à l’architecture 64 bits et 32 bits. Toutefois, la croissance excessive de la mémoire, entre autres considérations, peut entraîner une lenteur même dans le client 64 bits. Ces autres considérations incluent la mémoire système globale, les vitesses de disque (car la mémoire du programme est généralement sauvegardée par la mémoire virtuelle dans le fichier de pagination Windows), le nombre d’autres applications ouvertes, etc. Dans les deux cas, à mesure que l’empreinte mémoire Skype Entreprise augmente au fil du temps, plus elle sera mauvaise. Dans le cas du client 32 bits, cela peut entraîner l’insuffisance d’espace des objets plus volumineux dont Skype a besoin (par exemple, sa mémoire tampon interne pour le partage d’applications) et provoquer des défaillances.
Pour être juste, la mémoire n’est qu’une ressource consommée au fil du temps, mais elle est la plus évidente. L’utilisation de la gestion peut augmenter, les threads augmentent au fil du temps, la mémoire du pool paginé augmente, etc. Chacune de ces augmentations peut avoir un impact sur le processus et, dans certains cas, sur l’ensemble du système d’exploitation. C’est l’une des nombreuses raisons pour lesquelles nous suggérons, même pour le client 64 bits, que les utilisateurs quittent et redémarrent Skype quotidiennement (ou, au moins, chaque semaine) comme meilleure pratique.
Que dois-je faire à ce sujet et puis-je forcer Skype à redémarrer ?
Il existe plusieurs façons de forcer le redémarrage de Skype, mais il n’existe pas de méthode unique et optimale. L’une des façons, bien sûr, est l’éducation des utilisateurs. Les utilisateurs étant les arbitres de leur utilisation du bureau dans la plupart des cas, il est pragmatique de leur apprendre à se déconnecter et à fermer Skype lorsqu’ils quittent pour la journée. Cela peut également être effectué en tant qu’étape obligatoire en écrivant un script ou un exécutable personnalisé, puis en exécutant l’un d’eux en tant que tâche du planificateur de tâches. Cette approche est un peu ham-fisted, et peut entraîner le cycle de Skype même lorsqu’il est « en cours d’utilisation » (bien que cela puisse être atténué quelque peu par les conditions du planificateur de tâches). Il existe également des opportunités tierces pour la gestion des ordinateurs et des ordinateurs de bureau, des options bios potentielles, etc.
L’essentiel est qu’il est préférable pour Skype Entreprise de le faire cycle quotidiennement ou, au moins, chaque semaine. Si vous pouvez former vos utilisateurs à recycler Skype Entreprise régulièrement ( ou, au moins, lorsque les choses devenez bizarres), vous aurez probablement beaucoup moins d’appels au support technique et beaucoup plus d’utilisateurs heureux.