O Grande Mistério da Memória Skype for Business
Este artigo foi escrito por Kenn Guilstorf, engenheiro de escalonamento Skype for Business.
Como engenheiro de escalonamento, auxilio os clientes com alguns dos problemas mais "persnickety" Skype for Business. Ultimamente, recebi alguns casos que são "baseados em desempenho" – basicamente, as reclamações de que Skype for Business é lenta ou lenta, não permitem o compartilhamento de aplicativos ou simplesmente estão usando muita memória. Muitas vezes, uma investigação sobre esses casos mostra que o usuário deixou Skype for Business executar por semanas; e, com o tempo, a memória aumentou até afetar o desempenho. Até notei quando deixei o Skype correr por muito tempo. Então, o que o Skype está fazendo, e por que ele está segurando tanta memória? (Aqui está uma pequena dica: isso é normal e por design. Nada está errado – todo e qualquer programa nativo é executado para isso.)
Quanta memória pode mastigar?
A primeira etapa para corrigir qualquer problema é entender o problema e a primeira etapa para entender qualquer problema é defini-lo. Isso não é tão fácil de fazer quanto parece.
Quando Skype for Business (SfB) é iniciado pela primeira vez, o uso de memória é comparativamente pequeno (se você puder contar 100 MB como pequeno). Podemos ver isso ocorrer em várias ferramentas, como o Gerenciador de Tarefas:
Figura 1: Não se deixe enganar: Lync.exe é o nome do processo do SfB (versão de 32 bits)
Com o tempo, a quantidade de memória que o processo usa vai crescer. O tamanho do crescimento será determinado pelo quanto o Skype é usado, para o que ele é usado e assim por diante. Como exemplo, aqui está o mesmo cliente após cerca de 24 horas:
Figura 2: o mesmo SfB 24 horas depois
Portanto, o Skype consumiu cerca de 32 MB em 24 horas. Isso não é muito, certo? Não é realmente – até que eu explique que o Skype estava apenas sentado ocioso por todas essas 24 horas. Basicamente, comecei a Skype for Business em um computador, tranquei-o e esperei cerca de 24 horas antes de desbloqueá-lo. Em uso, o pedágio teria sido muito maior – especialmente se eu participasse de reuniões, usasse compartilhamento de aplicativos ou compartilhamento de área de trabalho nessas reuniões, usasse IM e assim por diante. Vi casos em que Skype for Business uso de memória cresceu para 300 a 500 MB em um único dia. As coisas podem ficar arriscadas após uma ou mais semanas de uso – especialmente no cliente de 32 bits com restrição de memória.
Mostre-me a memória
Há muitas ferramentas que podem perfilar memória. Uma das mais populares – pelo menos na Microsoft – é a VMap da ferramenta SysInternals, disponível na VMMap v3.26. Podemos usá-la para examinar a memória do processo e ver se podemos criar o perfil da memória Skype for Business.
Depois de baixar o VMap, execute-o. Ao iniciar, ele abrirá uma lista de processos para que você possa escolher o processo que deseja examinar. Vou escolher lync.exe e clicar em OK.
Figura 3: VMap no início
Em seguida, você verá um gráfico que é uma representação multicolorida do perfil de memória atual para o executável selecionado – Lync.exe, nesse caso.
Figura 4: VMap inicial para Lync.exe iniciado recentemente
Há muitas informações aqui, e descrever tudo isso preencheria uma ou mais postagens de blog próprias. Se você estiver interessado, há vários ótimos livros e artigos online que podem ajudar a explicar isso. (Pessoalmente, recomendo "Windows Avançado" de Jeffrey Richter – atualmente sem impressão, mas ainda excelente em explicar como a memória funciona. Você pode encontrar cópias usadas dele em seu repositório de livros favorito.)
Como você pode ver, a memória mostrada no Gerenciador de Tarefas não está alinhada com nenhuma categoria no VMap. O Gerenciador de Tarefas é uma representação mais generalizada; é preciso, só não conta tudo. O VMMap é muito mais abrangente.
Aqui está nossa instância do Skype após o período de espera de 24 horas:
Figura 5: VMap para Skype após 24 horas
Onde está a memória?
Se você comparar cada categoria individual, nada realmente se alinha. Na verdade, encontrar o que está consumindo a memória é difícil de fazer porque as categorias de memória flutuam à medida que objetos e solicitações de memória são feitos e liberados, e a memória fica reservada e comprometida para armazenar vários objetos. O "kernel de conhecimento" (para fins deste blog, de qualquer maneira) é a categoria "Livre". Em nosso exemplo, a memória "gratuita" é todo o espaço disponível que é "reservado" para o executável do Lync. Mas apenas um determinado tipo de memória "comprometida" é mostrado no Gerenciador de Tarefas. A memória reservada não é contada porque não está em uso.
Então, onde está a memória? Isso se torna difícil de identificar porque a memória não está perdida. Ao contrário da crença popular, a equipe do Skype não foi subsidiada pelos fabricantes de memória da área de trabalho. Não há nenhum plano nefasto para fazer com que os clientes atualizem sistemas ou memória. Isso nem é um caso de obsolescência planejada. A verdade é um pouco mais difícil de explicar.
Vamos retroceder um pouco para tornar as coisas mais claras. Quando você inicia o cliente Skype for Business pela primeira vez, ele tem uma pegada de memória relativamente pequena – normalmente de 100 MB ou mais, dependendo do número de contatos que ele controla para você e outras sobrecargas (você pode ver claramente isso nos dados acima). Depois de alguns dias, você perceberá que essa pegada aumenta várias centenas de milhares de bytes para vários megabytes. Em determinadas situações, isso pode ser um problema – mas não é necessariamente um problema em Skype for Business si mesmo. Em vez disso, é um efeito do paradigma de programação do Windows e como ele lida com a memória nativamente.
Programação do Windows o quê?
Só vou dar uma visão simplista da memória do Windows aqui. A memória do Windows é tratada por meio de procedimentos caros (em termos de ciclos e recursos de computador) conhecidos como alocações e des alocações. Quando um programa precisa de memória, ele pede ao Windows para alocá-lo. Quando ele é passado com a memória, o programa pede ao Windows para deslocá-lo. Internamente, o Windows passa por vários processos para gerenciar as solicitações de memória.
Quando uma solicitação é feita, o Windows verifica a memória que ele já se comprometeu com o processo, mas que o processo não está sendo usado. O Windows está procurando ver se há um bloco de memória grande o suficiente para usar. Se houver, o sistema o usa e segue seu caminho alegre. Se não houver, ele verificará a memória reservada. Se houver um bloco grande o suficiente de memória reservada, ele a confirmará (em partes definidas pelo sistema operacional conhecidas como "páginas") e armazenará a variável nela. A memória agora está comprometida, e acabamos de crescer a pegada de memória do executável.
O que acontece se não houver memória reservada suficiente para lidar com a solicitação? O sistema operacional tenta reservar mais memória – se puder. Aqui é onde a diferença entre a arquitetura de 32 bits e a arquitetura de 64 bits entra em jogo. Um processo de 32 bits pode usar apenas um máximo de 4 GB de memória. Isso ocorre porque 4 GB é a quantidade máxima que um registro de 32 bits pode resolver. (Um bit só pode conter um 1 ou um 0 – binário. Portanto, 32 bits significa que 232 é o endereço mais alto permitido). Graças à arquitetura de 32 bits, apenas cerca de 2 GB dessa memória são atribuídos ao processo em si, o restante sendo usado pelo sistema operacional para mapear DLLs comuns, cuidar de objetos comuns do modo kernel e assim por diante. Em um sistema de 64 bits, os registros longos de 64 bits podem lidar com 264, o que acaba sendo cerca de 18 exabytes. No entanto, o Windows limita artificialmente a quantidade de memória disponível para ser reservada entre 2 terabytes e 4 terabytes (TB), dependendo da versão do Windows.
Depois que a memória for reservada, ela será confirmada e usada como antes. O processo de des alocação é em grande parte o inverso - exceto para um ou dois detalhes pequenos, mas importantes.
Primeiro, a menos que solicitado, o Windows nunca "limpa" a memória. Quando a memória é deslocada, ela é marcada como gratuita no mapa de memória do Windows. O que quer que ele tenha mantido ainda está lá e permanecerá lá até que seja substituído por outra alocação. Em seguida, o Windows raramente descompõe a memória, a menos que seja solicitado. Como eu disse anteriormente, as operações de memória são bastante caras em recursos. Portanto, se um programa precisasse da memória alocada anteriormente, o Windows assumirá que ele pode precisar dessa memória novamente e adiará o descompanhamento da memória até que ela precise absolutamente. Por fim, o Windows nunca "agrupa" a memória. Isso significa que a memória que o Windows libera nunca é "agregada", e blocos de memória livre nunca são "movidos juntos" para fazer blocos maiores de memória livre. (Todas essas funções são agrupadas em uma categoria conhecida como "coleta de lixo". .NET Framework famosamente tem alguns recursos de coleta de lixo. No entanto, Skype for Business é um aplicativo "nativo" ou non-.NET.)
Skype for Business processa muitos objetos a cada segundo que são variavelmente dimensionados. Ele tem que fazer isso para ser a ferramenta impressionante que queremos que seja. Pedimos que ele gerencie contatos, gerencie calendários (reuniões), IM com nossos amigos, parentes e colegas e até fale com eles usando voz e vídeo, compartilhe áreas de trabalho ou janelas e assim por diante. Bem, para citar o falecido, grande Robert Heinlein, entre outros: "Não existe tal coisa como um almoço grátis."
O gerenciamento de tantos objetos de tamanhos tão diferentes e muitas vezes variáveis cria alocações e desa alocações de partes de memória de tamanho variável. Com o tempo, isso causa fragmentação de memória – às vezes grave – que aumenta a pegada de memória de Skype for Business.
Um exemplo pode ilustrar melhor este ponto. Vamos supor que o Skype (ou qualquer programa nativo, na verdade) aloca 64 objetos, numerados de 1 a 64, que são 4 bytes K cada um em tamanho:
Figura 6: 64 Objetos, cada um usando 4 KB de memória
Isso causa uma alocação e compromisso de memória de 256 KB. Agora, vamos supor que o programa não exija os objetos com numeração uniforme, portanto, ele os libera:
Figura 7: Liberar todos os objetos com numeração uniforme libera 128 KB de memória!
Se você examinar a imagem maior da memória geral (usando o VMMap ou uma ferramenta semelhante), verá que uma das colunas comprometidas (provavelmente na seção Heap , mas depende exatamente de como o programa solicitou a memória) tem 128 KB a menos e a seção Livre cresceu 128 KB. No Gerenciador de Tarefas, o programa agora possui apenas 128 bytes de memória KB.
Em seguida, vamos supor que nosso programa tenha um único objeto de 8 KB que ele tem que armazenar. Isso deve ser simples. Afinal, ele tem 128 KB gratuitos. No entanto, tentar armazenar esse objeto de 8 KB criará uma nova reserva de memória em vez de armazenar a memória no espaço livre de 128 KB. Isso ocorre porque, se você olhar para a memória, poderá ver que ela ainda é segmentada em partes de 4 KB! O Windows não tem um bloco de memória grande o suficiente para manter o objeto de 8 KB, portanto, ele precisa reservar e confirmar mais memória no programa.
Este é um exemplo bastante inventado, mas ilustra a dificuldade do gerenciamento de memória do Skype. O Skype gerencia um grande número de objetos que não têm um tamanho facilmente definível. Esses objetos são todos variavelmente longos. Isso significa que, à medida que os objetos são armazenados e liberados – especialmente por um longo período de tempo, como dias ou semanas – a fragmentação de memória pode se tornar severa e, como o Windows precisa alocar mais memória para armazenar os novos objetos, a pegada de memória cresce excessivamente.
Quando isso causa problemas no cliente de 32 bits, frequentemente sugerimos mudar para o cliente de 64 bits porque a memória é muito menos restrita lá, graças à arquitetura de 64 bits versus 32 bits. No entanto, o crescimento excessivo da memória, entre outras considerações, pode causar lentidão até mesmo no cliente de 64 bits. Essas outras considerações incluem memória geral do sistema, velocidades de disco (porque a memória do programa normalmente é apoiada pela memória virtual no arquivo de paginação do Windows), quantos outros aplicativos estão abertos e assim por diante. Em ambos os casos, à medida que o Skype for Business pegada de memória cresce ao longo do tempo, pior será o desempenho. No caso do cliente de 32 bits, isso pode fazer com que os objetos maiores que o Skype exige – como seu buffer interno para compartilhamento de aplicativos – fiquem sem espaço e causem falhas.
Para ser justo, a memória é apenas um recurso que é consumido ao longo do tempo , mas é o mais óbvio. O uso do identificador pode crescer, os threads aumentarão ao longo do tempo, a memória do pool de páginas aumentará e assim por diante. Cada um desses aumentos pode ter um impacto no processo e, em determinados casos, em todo o sistema operacional. Essa é uma das inúmeras razões pelas quais sugerimos – mesmo para o cliente de 64 bits – que os usuários saiam e reiniciem o Skype diariamente (ou, pelo menos, semanalmente) como uma prática recomendada.
O que eu faço sobre isso, e posso forçar o Skype a reiniciar?
Há várias maneiras de forçar uma reinicialização do Skype, mas não há uma única e melhor maneira. Uma maneira, é claro, é a educação do usuário. Os usuários são os árbitros do uso da área de trabalho na maioria dos casos, por isso é pragmático ensiná-los a sair e fechar o Skype quando saem para o dia. Isso também pode ser feito como uma etapa obrigatória, escrevendo um script personalizado ou executável e executando um como tarefa agendador de tarefas. Essa abordagem é um pouco dura e pode fazer com que o Skype pedale mesmo quando está "em uso" (embora isso possa ser atenuado um pouco através das condições do Agendador de Tarefas). Há também oportunidades de terceiros para gerenciamento de computadores e área de trabalho, possíveis opções de BIOS e assim por diante.
A questão é que é melhor para Skype for Business pedalá-lo diariamente – ou, pelo menos, semanalmente. Se você puder treinar seus usuários para reciclar Skype for Business regularmente – ou, pelo menos, quando as coisas ficarem estranhas – provavelmente você terá muito menos chamadas do Helpdesk e muitos usuários felizes.