Entendendo o uso de memória no Linux

Por que, afinal, um simples editor de texto do KDE (kedit) ocupa em torno de 25 Megabytes de memória?

Perguntas como essa são bastante comuns entre usuários e administradores de sistemas Linux. Sendo que muitos deles são levados a acreditar que as aplicações desse sistema operacional, especialmente nos ambientes KDE e Gnome, usam uma grande e desnecessária quantidade de memória, baseados nos valores obtidos por ferramentas como o ps.

Enquanto essa afirmação pode ser ou não verdade, ela não deve ser considerada uma regra geral, já que depende exclusivamente das circunstâncias em que o programa está sendo executado. O fato é que, como veremos a seguir, diversos programas são muito mais eficientes no uso da memória do que parecem ser.

Este artigo – uma tradução livre e adaptada do original Understand memory usage on Linux – tenta justificar os resultados do ps referentes à quantidade de memória usada por um processo, e demonstrar através de outra ferramenta uma maneira de se obter valores mais coerentes.

A ferramenta ps

Para usuários que ainda não tiveram muito contato com o console, vulgo “linha de comando”, o ps é uma ferramenta extremamente útil para conseguir informações sobre os processos, como, por exemplo, o PID (número de identificação do processo), o estado de execução e a utilização de recursos (Memória e CPU). Entre os valores possíveis de se obter com o ps estão o VSZ e o RSS, que são, respectivamente, a quantidade de memória virtual (virtual set size) e a quantidade de memória residente (resident set size). Esses valores são geralmente usados para verificar a quantidade de memória ocupada por um processo.

Eis um exemplo de resultado do comando ps, mostrando apenas o processo do programa KEdit:

De acordo com esse resultado, o KEdit está ocupando uma quantidade de memória virtual em torno de 25 Megabytes e memória residente em torno de 14 Megabytes (ambos os valores estão em Kilobytes). Existem divergências sobre qual desses valores representa a quantidade real de uso de memória do processo. Usuários e administradores tendem a escolhê-los aleatoriamente, e, no momento, explicar a diferença entre os valores VSZ e RSS não interessa à discussão, já que nenhum deles pode ser considerado o valor exato da quantidade de memória usada pelo KEdit.

Por que o ps está errado?

Dependendo de como se observa o resultado do ps, ele não aponta para a quantidade exata de memória usada pelos processos. O que o seu resultado realmente mostra é a quantidade de memória que usaria determinado processo se ele fosse o único processo em execução. Logicamente, um sistema Linux possui dezenas de processos em execução ao mesmo tempo, o que torna definitivamente os valores VSZ e RSS “errados”. A fim de entender porque razão, é necessário saber como o Linux lida com as bibliotecas compartilhadas nos programas.

Uma biblioteca compartilhada é uma coleção de subprogramas utilizados para facilitar o desenvolvimento de programas, permitindo o compartilhamento e a alteração de código e dados de forma modular. A maior parte dos sistemas operacionais modernos provê bibliotecas que implementam a maioria dos serviços do sistema. Assim sendo, muitos dos programas no Linux utilizam as bilbliotecas compartilhadas para facilitar determinadas funcionalidades.

Por exemplo, o programa KEdit usa várias bibliotecas compartilhadas do KDE (para fazer a interação com outros componentes do KDE), bibliotecas do X Window (para desenhar as imagens e funções de copiar e colar), além das diversas bibliotecas do sistema que realizam as operações básicas. Muitas dessas bibliotecas compartilhadas, especialmente aquelas comumente usadas como a libc, são acessadas por vários programas em execução no sistema. Devido a esse compartilhamento, o Linux é capaz de usar um grande truque: ele carrega uma única cópia da biblioteca compartilhada na memória, e usa essa cópia para todos os programas que fazem referência a ela.

Para bem ou para mal, muitas ferramentas, assim como o ps, não se preocupam com esse comportamento do sistema. Elas simplesmente mostram quanto de memória um processo está ocupando, independente se esta memória está sendo compartilhada com outros processos. Dois programas poderiam, portanto, utilizar a mesma biblioteca compartilhada, e mesmo assim ter o tamanho dessa biblioteca contabilizado na memória total de ambos os processos. Dessa maneira, a quantidade de memória ocupada pela biblioteca está sendo contabilizada duas vezes, gerando resultados enganadores caso não se saiba o que está realmente acontecendo.

Infelizmente, um valor exato da quantidade de memória ocupada por um processo não é algo fácil de se obter. Não só é necessário saber como o sistema funciona, mas também decidir como lidar com algumas questões complexas. Se uma biblioteca compartilhada é usada apenas por um processo, o seu tamanho deve ser contabilizado apenas para esse processo? Se uma biblioteca compartilhada é usada por múltiplos processos, a quantidade de memória ocupada por ela deve ser distribuída entre os diferentes processos, ou apenas ignorada? Não existe uma regra fixa neste caso, pois cada situação terá uma resposta diferente. Assim fica fácil de entender a razão do ps não se esforçar para calcular um resultado mais “correto” do uso de memória, dada a ambigüidade.

Visualizando o mapa da memória

Apesar da imprecisão em relação aos resultados do ps, o Linux fornece um comando para visualizar o mapa da memória de um processo, permitindo assim analisar mais precisamente como um processo está utilizando a memória. Esse comando é o pmap, que com a opção “-d”, produz o seguinte resultado para o processo do KEdit:

Uma parte do resultado do comando foi omitida, já que é similar ao trecho que foi apresentado. Mesmo sem o resultado completo, é possível verificar alguns pontos interessantes. Um deles a ser observado é que cada biblioteca compartilhada (iniciadas por “lib”) são listadas duas vezes: uma para o segmento de código e outra para o segmento de dados. O segmento de código tem a coluna referente ao modo em “r-x–“, enquanto o segmento de dados possuí o modo “rw—“.

Com base nessa informação, dá para concluir que os segmentos de código das bibliotecas compartilhadas são as que ocupam a maior quantidade de memória, de acordo com a coluna Kbytes. A boa notícia em relação a isso é que justamente essa memória pode ser compartilhada com outros processos em execução. Subtraindo a quantidade de memória ocupada pelas bibliotecas compartilhadas, chega-se ao valor especificado em “writeable/private”, mostrado no final do resultado do pmap. Esse valor pode ser considerado a quantidade real de memória usada pelo processo. Portanto, a quantidade de memória ocupada pelo KEdit, pressupondo que todas as bibliotecas compartilhas foram previamente carregadas, é de aproximadamente 2 Megabytes. Valor definitivamente mais coerente se comparado aos 14 ou 25 Megabytes mostrados pelo comando ps.

Conclusão

A moral da história é que o uso de memória no Linux é uma questão complexa. Não basta apenas rodar o comando ps para saber o que realmente está acontecendo, principalmente quando estiver lidando com programas que criam muitos processos filhos, como é o caso do servidor Web Apache. O comando ps poderá mostrar que cada processo do Apache ocupa 10 Megabytes de memória, quando na realidade essa quantidade é normalmente algo em torno de 1 Megabyte. Esse tipo de informação se torna crítica para realizar uma análise de desempenho do Apache e configurar variáveis como o MaxClients, que determina quantas conexões o servidor Web poderá processar simultaneamente.

Também com base no uso das bibliotecas compartilhadas, reforça-se a idéia de manter apenas aplicações de um único ambiente desktop, como KDE ou Gnome. Caso várias aplicações do Gnome estejam rodando em um ambiente KDE, ou vice-versa, o sistema pagará caro pela quantidade de bibliotecas compartilhadas com a mesma função. Todavia, mantendo aplicações de um único ambiente, o sistema irá reduzir a quantidade de uso de memória, permitindo que o Linux use-a para recursos mais interessantes, como, por exemplo, o cache de arquivos, que acelera consideravelmente o acesso ao sistema de arquivos.

Referências

Devin (04-02-2006). Understand memory usage on Linux. Virtual Threads. Acessado em 15-02-2008.
Wikipédia (09-02-2008). Library (computer science). Acessado em 17-02-2008.