Procfs do Linux para administradores: visão geral dos ficheiros importantes

O Linux procfs mostra o estado atual do kernel através de ficheiros virtuais na diretória /proc. Para a administração, são especialmente relevantes a carga, a memória, os processos, os descritores de ficheiros e os dispositivos de bloco. O importante é a interpretação: alguns valores são instantâneos, outros são contadores acumulados desde o arranque ou médias móveis. Por isso, nunca analises apenas um valor isolado, mas compara-o com os sinais adequados e o contexto do anfitrião, da máquina virtual ou do contentor.

Compreender o procfs: uma visão virtual do kernel em vez de um armazenamento de dados

O procfs é um sistema de ficheiros virtual: as entradas em /proc representam estruturas de dados e estados do kernel Linux em execução. Não se tratam de conteúdos armazenados de forma permanente num suporte de dados. Durante a leitura, o kernel gera a respetiva visão a partir do seu estado atual; após um reinício, por exemplo, muitos contadores recomeçam do zero. Por isso, /proc é uma interface para observação e, em parte, controlo, não sendo um local para ficheiros próprios ou configurações persistentes.

No que diz respeito à administração, é necessário distinguir três áreas. Os ficheiros de estado globais, como /proc/meminfo, /proc/stat ou /proc/loadavg, fornecem indicadores relativos a todo o kernel. Os diretórios com nomes numéricos, como /proc/1234, fornecem detalhes sobre um processo específico. Por outro lado, em /proc/sys encontram-se os parâmetros do kernel, que podem ser tanto de leitura como de escrita, dependendo das permissões e dos parâmetros em questão. A semelhança na estrutura dos ficheiros não deve induzir em erro: a consulta do estado e a alteração da configuração têm consequências fundamentalmente diferentes.

Os caminhos e campos disponíveis não são idênticos em todos os sistemas Linux. A versão e a configuração do kernel, a arquitetura, o hardware reconhecido e os módulos carregados influenciam as entradas visíveis. Os namespaces também alteram as visualizações individuais. Um procfs associado a um namespace de PID limita, em particular, a perspetiva do processo e do PID; no entanto, isso não significa que os ficheiros globais apresentem automaticamente valores específicos de um contentor ou de um cgroup. Os scripts devem verificar os ficheiros e os campos antes de analisar o seu conteúdo, em vez de pressuporem uma estrutura procfs completa e idêntica em todos os casos.

É importante distinguir isto do sysfs, localizado em /sys: este apresenta, sobretudo, dispositivos, controladores e objetos de hardware. O cgroup2 é também relevante para a distribuição de recursos e os limites dos grupos. No entanto, o procfs continua a ser a fonte direta de muitos estados do kernel e dos processos, necessários num primeiro diagnóstico.

Interpretar corretamente os indicadores, os instantâneos e a visibilidade

No caso do procfs, o valor por si só raramente explica um problema. Em primeiro lugar, é necessário esclarecer a sua referência temporal: alguns dados são contadores cumulativos desde o arranque do sistema; outros descrevem um estado atual; outros ainda representam intervalos de tempo móveis. Um valor elevado do contador indica, numa primeira fase, apenas que um evento se acumulou desde o arranque. Uma taxa só surge a partir de dois pontos de medição: a diferença entre os valores dividida pelo intervalo de tempo entre eles. Isto aplica-se, por exemplo, a muitos contadores de CPU, de interrupções e de suportes de dados.

O ficheiro /proc/uptime fornece o tempo de funcionamento decorrido e o tempo de inatividade agregado. Ajuda a contextualizar os contadores em termos temporais desde o arranque, mas não substitui uma série de medições. Uma consulta única é um instantâneo; para obter conclusões fiáveis sobre tendências, picos ou cargas recorrentes, são necessárias consultas repetidas com carimbo de data/hora. Nesse contexto, os valores podem já ter mudado durante a leitura, porque o kernel continua a funcionar.

Os dados visíveis também têm limitações. O /proc/self aponta sempre para o processo que está a resolver o caminho nesse momento. Isto torna-o prático para scripts e verificações interativas, sem ser necessário assumir um PID. No entanto, o acesso a diretórios de processos de outros processos pode ser restringido por direitos de ficheiro, capacidades do Linux e pela opção de montagem procfs hidepid pode ser limitada. A falta de acesso a certas informações, neste caso, não se deve a uma falha no procfs, mas sim a uma medida de proteção contra a leitura de informações sensíveis sobre os processos.

É necessário ter especial cuidado nos contentores. Um procfs vinculado a um namespace PID apresenta, nos caminhos relacionados com processos, apenas os processos dessa perspetiva do namespace. Por outro lado, ficheiros globais do kernel, como /proc/meminfo, /proc/stat ou /proc/diskstats, podem continuar a refletir valores do anfitrião e não são automaticamente limitados aos limites do contentor. Por isso, antes de qualquer diagnóstico, é necessário esclarecer se a questão diz respeito a processos, a valores globais do kernel ou aos recursos efetivamente atribuídos; os limites e a utilização de um contentor devem, além disso, ser incluídos na análise do cgroup2.

Ler, configurar e proteger em /proc/sys

A área /proc/sys é a vista do sistema de ficheiros da interface sysctl. A leitura de um valor serve para fins de diagnóstico. Por outro lado, o acesso de escrita altera imediatamente o comportamento do kernel em execução e pode afetar serviços, o consumo de recursos ou características de segurança. O facto de uma alteração surtir efeito sem reinicialização não significa que seja isenta de riscos nem que seja automaticamente permanente: a persistência depende da configuração do sistema selecionada.

A estrutura de diretórios facilita a orientação inicial. Em /proc/sys/fs encontram-se, entre outros, parâmetros globais do sistema de ficheiros e dos identificadores de ficheiros. /proc/sys/vm agrupa as configurações da gestão de memória, enquanto /proc/sys/net contém parâmetros relacionados com a rede. Os subdiretórios e chaves disponíveis dependem, por sua vez, da configuração do kernel e das funcionalidades do sistema. Um parâmetro existente não constitui, portanto, uma receita geral de otimização; a sua documentação e a carga de trabalho concreta são determinantes.

Um contra-exemplo de otimização aparente é drop_caches em /proc/sys/vm. A documentação do kernel classifica esta função como destinada à depuração e a testes e desaconselha a sua utilização para outros fins, uma vez que esvaziar as caches reutilizáveis pode comprometer o desempenho. A escassez de memória livre, por si só, não é motivo para eliminar caches: o kernel utiliza deliberadamente a RAM também para o cache de ficheiros.

Antes de qualquer alteração, deve existir uma causa compreensível. Registe primeiro o valor inicial, documente o objetivo e os efeitos secundários esperados, efetue a alteração de forma controlada e, em seguida, observe os valores de medição adequados, bem como o comportamento do serviço. Planeie antecipadamente o caminho de regresso e só transfira um valor para uma configuração permanente após uma verificação técnica. O artigo aborda noções básicas adicionais sobre parâmetros e a sua gestão controlada Afinação do kernel no alojamento Linux: parâmetros Sysctl em resumo.

Os ficheiros procfs mais importantes por tarefa administrativa

A escolha de um ficheiro procfs deve partir de uma perspetiva de administração, e não de uma lista de diretórios o mais completa possível. Os ficheiros globais fornecem frequentemente valores a nível do kernel, os caminhos dos processos descrevem um único processo visível e as entradas em /proc/sys/fs fornecem configurações e limites a nível do sistema. Alguns valores representam estados atuais, outros são contadores acumulados desde o arranque ou médias móveis. Esta distinção determina se basta uma única leitura ou se são necessários dois pontos de medição.

A tabela serve como um ponto de partida, não como uma cadeia de diagnóstico. Um valor anómalo exige sempre uma verificação independente: a carga com dados da CPU e de E/S, os valores de memória com a informação de «Pressure Stall» e os parâmetros do processo com o comportamento do serviço. Em particular, /proc/diskstats e /proc/stat são contadores cumulativos; a sua variação ao longo de um intervalo conhecido é mais reveladora para as taxas do que o valor absoluto. Nos contentores, é necessário verificar adicionalmente se um ficheiro fornece valores globais do kernel ou uma visão disponível por cgroup. Por isso, as secções seguintes classificam os sinais por carga, memória, processos e E/S.

Carga, CPU e memória: avaliação combinada dos sinais

Quando o sistema está lento, o /proc/loadavg é um bom ponto de partida, mas não constitui um diagnóstico definitivo sobre o desempenho da CPU. Os três valores representam a carga média dos últimos 1, 5 e 15 minutos. A carga inclui não só as unidades prontas para execução no estado R, mas também as tarefas no estado de espera ininterruptível D, por exemplo, em operações de E/S. O quarto campo mostra as unidades de agendamento atualmente executáveis em comparação com todas as unidades de agendamento existentes. Elevado Média de carga pode, por isso, indicar concorrência na CPU, acessos de E/S bloqueados ou ambos.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

As linhas relativas à CPU em /proc/stat contêm os tempos decorridos desde o arranque do sistema em USER_HZ. Para determinar as percentagens de utilização a partir destes dados, é necessário comparar duas leituras; uma única leitura mostra apenas o tempo acumulado. O valor iowait não é, neste contexto, uma medida direta da latência do armazenamento: o seu cálculo tem limites documentados e pode, em determinadas circunstâncias, até diminuir. Por isso, para identificar uma causa relacionada com E/S, é útil consultar adicionalmente os valores dos dispositivos e o I/O-PSI.

Mesmo um valor baixo em MemFree não significa necessariamente que haja falta de RAM. O Linux utiliza a memória não utilizada especificamente para o cache. O MemAvailable estima a quantidade de memória que as novas aplicações poderão provavelmente receber sem recorrer ao swapping e é, na maioria das vezes, mais útil para uma primeira avaliação. Só quando o MemAvailable se torna escasso e, ao mesmo tempo, ocorrem bloqueios de memória, é que se torna mais evidente a indicação de pressão de armazenamento. No entanto, num contentor, estes valores de memória globais podem provir do anfitrião; no caso de recursos garantidos ou limitados, a perspetiva do cgroup2 é também determinante.

Os ficheiros em /proc/pressure complementam esta perspetiva. No caso de «memory» e «io», «some» significa que, pelo menos, algumas tarefas ficaram paralisadas durante uma parte do intervalo de tempo; «full» indica um estado em que todas as tarefas não inativas estavam bloqueadas simultaneamente. Os valores «avg10», «avg60» e «avg300» referem-se a 10, 60 e 300 segundos, respetivamente, enquanto «total» é um contador acumulado de bloqueios. No caso da CPU, o valor «full» a nível do sistema não está semanticamente definido e, desde o Linux 5.13, é apresentado como zero por motivos de compatibilidade; por conseguinte, não deve ser interpretado como um valor de diagnóstico a nível do sistema. Os PSI de CPU, memória e E/S respondem a questões diferentes e não devem ser utilizados de forma intercambiável.

Se um serviço reagir lentamente quando o MemFree estiver baixo, verifica primeiro o MemAvailable e o /proc/pressure/memory. Se ambos estiverem normais, isso indica que não existe uma pressão aguda de memória a nível do sistema. Em seguida, o ficheiro /proc//status pode indicar se o processo em questão apresenta, por exemplo, um valor elevado de VmRSS, muitos threads ou um estado anómalo. Esta combinação permite distinguir uma utilização de memória normal, mas com grande carga no cache, de um problema que exija uma análise mais aprofundada do processo.

Analisar processos, descritores de ficheiros e E/S de dispositivos de armazenamento

Para um exercício seguro com um processo cuja existência é garantida, $$ representa o PID do shell atual. O ficheiro «status» é mais legível para o utilizador do que o ficheiro «stat», orientado por campos. O nome identifica o processo, o estado indica a sua condição, o PPid refere-se ao processo pai e «Threads» indica o número de threads. O VmRSS é uma aproximação rápida da memória residente, cujo registo RSS é escalável e assíncrono, podendo, por isso, ser impreciso; o VmSize, por outro lado, descreve o espaço de endereçamento virtual. O FDSize descreve o tamanho da tabela de descritores, não necessariamente o número de entradas atualmente abertas. As mudanças de contexto voluntárias e involuntárias podem ajudar a classificar o comportamento de agendamento, mas, por si só, não constituem prova de erro.

cat /proc/$$/status
ls -l /proc/$$/fd

O diretório fd contém ligações simbólicas para ficheiros abertos, pipes, dispositivos ou sockets. Ajuda, por exemplo, a identificar um processo que continua a manter aberto um ficheiro de registo que já foi eliminado. No entanto, é perfeitamente normal que haja um grande número de descritores de ficheiros abertos em proxies, bases de dados ou servidores orientados para eventos. Para visualizações filtradas e a atribuição entre processos, é Utilizar o lsof para analisar ficheiros abertos um complemento adequado. As linhas de comando do cmdline podem revelar argumentos confidenciais; o environ é ainda mais sensível devido à possibilidade de conter dados de acesso ou tokens, pelo que não deve ser consultado de forma rotineira.

O comando `maps` lista áreas de memória virtual com permissões, deslocamento, dispositivo, inode e, se for o caso, caminho. O comando `smaps` complementa, para cada mapeamento, valores detalhados da memória e fornece um instantâneo mais preciso do que as informações do RSS, embora seja mais complexo. Ambos os ficheiros destinam-se a análises aprofundadas da memória: a sua saída pode ser volumosa e a interpretação de cada mapeamento requer contexto. Para uma primeira análise, o comando `status` e os ficheiros de memória e PSI a nível do sistema são, na maioria das vezes, mais eficientes.

Em caso de carga elevada e baixa utilização da CPU, o ficheiro /proc/diskstats alarga o diagnóstico ao nível dos dispositivos. O ficheiro mantém estatísticas cumulativas de E/S por dispositivo de bloco. Para avaliar a atividade em termos de taxa, é necessário comparar dois momentos no tempo. Nesse contexto, é importante distinguir claramente entre unidades físicas, partições e dispositivos virtuais ou do Device Mapper; os contadores de diferentes níveis não devem ser somados indiscriminadamente. Um descritor de ficheiro aberto de um processo não pode ser atribuído diretamente a um contador de dispositivo do `diskstats`: o sistema de ficheiros, a cache e as camadas de mapeamento intercalam-se entre eles. No entanto, em conjunto com /proc/pressure/io, é possível verificar se os bloqueios de E/S observáveis e a atividade do dispositivo coincidem no tempo.

O procfs em funcionamento: consultas, monitorização e proteção de dados

Para realizar diagnósticos operacionais repetíveis, deve tratar as consultas ao procfs como pontos de medição: anote o carimbo de data/hora, o contexto do sistema e a consulta específica. Muitos valores são contadores acumulados desde o arranque; só a diferença entre dois valores, dividida pelo intervalo de tempo, resulta numa taxa. Isto aplica-se, por exemplo, aos contadores de /proc/diskstats. Uma consulta isolada pode, portanto, comprovar a existência de atividade, mas não permite quantificar de forma fiável nem o débito nem uma deterioração duradoura.

Um sistema de monitorização deve, entre outras coisas, recolher valores armazenados em intervalos fixos a partir de /proc/meminfo, valores dos aparelhos de /proc/diskstats, registar os estados dos processos e do sistema, bem como os sinais de impressão, caso exista suporte do kernel. Deve converter os valores brutos em unidades adequadas, calcular diferenças no caso de contadores e guardar históricos. Nos contentores, não deve equiparar os valores globais do procfs aos limites de recursos da carga de trabalho: os percursos dos processos podem estar limitados ao espaço de nomes do PID, enquanto os valores de memória ou de dispositivos refletem, em parte, o anfitrião. Para os limites e a utilização de um grupo, são necessárias métricas cgroup2 complementares. Só as tendências temporais permitem definir limiares fiáveis: um valor elevado pode ser normal se se enquadrar na janela de carga esperada; um aumento repentino em relação à sua própria linha de base é frequentemente mais relevante. As entradas procfs disponíveis dependem do kernel em execução e da sua configuração.

Os ficheiros diretos e as ferramentas complementam-se. ps, top ou htop são adequados para a visualização interativa do processo; free, vmstat, iostat, pidstat, ss e sar Dependendo da instalação, preparam dados para questões específicas. O procfs continua a ser útil se quiseres verificar diretamente o código-fonte do kernel ou criar um pequeno script fácil de compreender. Para alertas e planeamento de capacidade, os dados de séries temporais são, na maioria das vezes, o nível mais adequado.

Mesmo nas consultas exclusivamente de leitura, aplicam-se limites de visibilidade. Os direitos de acesso, as opções de montagem e os espaços de nomes PID podem ocultar dados do processo ou limitá-los a uma vista do contentor. Por outro lado, o facto de um contêiner ter a sua própria montagem /proc não significa que cada ficheiro global do kernel contenha apenas dados desse contêiner. A ausência de uma entrada de processo ou um valor global inesperadamente elevado é, por isso, um indício de que é necessário esclarecer o ambiente de execução, as opções de montagem e o contexto do cgroup.

Percursos de diagnóstico para serviços lentos e estrangulamentos de recursos

A resolução de problemas começa com um sintoma, não com um valor isolado supostamente responsável. Em seguida, verifica, pelo menos, um sinal independente e regista se a observação diz respeito ao anfitrião, a uma máquina virtual ou a um contentor. Desta forma, evita-se, por exemplo, interpretar precipitadamente uma carga elevada como um problema da CPU ou um grande número de descritores abertos como uma fuga de memória. Os passos seguintes constituem um primeiro diagnóstico orientativo e não substituem os registos específicos da aplicação.

Quando a média de carga for elevada, verifica primeiro se são as tarefas em execução ou em espera que estão a influenciar esse valor. Os dados de carga representam valores médios ao longo de um, cinco e 15 minutos e têm em conta tanto os estados R como os estados D. Por isso, compara os campos de tempo de CPU com a pressão de E/S e a atividade dos dispositivos apenas com cautela. Em particular, iowait não deve ser interpretado isoladamente como latência de memória.

Se a aplicação for lenta e o MemFree for pequeno, então MemDisponível o melhor valor inicial de contexto. Adicione o PSI de memória e o estado do processo em questão, como o seu VmRSS, o número de threads e o estado. O PSI distingue, no que diz respeito à memória e às E/S, entre some para tarefas parcialmente bloqueadas e full para o bloqueio total de tarefas que não estejam em estado de inatividade. A ausência de ficheiros PSI pode dever-se à configuração do kernel ou ao ambiente; tal não indica necessariamente a existência de um gargalo.

Para o diagnóstico de ficheiros e processos, podem ser necessários direitos e Espaços de nomes PID limitar a relevância da informação. Em ambientes de contenção, o /proc descreve frequentemente apenas o ambiente de processos atribuído. Por isso, em caso de acesso recusado ou de diretórios incompletos, deve verificar os direitos do utilizador, as opções de montagem do procfs e o contexto do namespace antes de tirar qualquer conclusão técnica com base na ausência de dados.

Corrigir equívocos comuns e escolher as ferramentas adequadas

Na administração do Linux, quatro erros de julgamento levam frequentemente à adoção de medidas erradas. Poucos MemFree não significa automaticamente falta de RAM, porque o kernel utiliza a memória, entre outras coisas, como cache; para novas aplicações, o MemAvailable é a estimativa mais significativa. Uma carga elevada não comprova a saturação da CPU, uma vez que também são incluídas tarefas em espera ininterrupta. Uma proporção elevada de iowait não mede a latência imediata de um suporte de dados. E o procfs não é idêntico em todos os casos: a versão do kernel, a configuração, o hardware, os módulos e os namespaces influenciam os ficheiros e os campos.

Escolhe o método de acordo com a questão. Para uma análise pontual das causas, fornece procfs Dados brutos diretos do kernel em execução. Para obter uma visão geral rápida e legível, as ferramentas especializadas de linha de comandos são, na maioria das vezes, mais eficientes. Quando o que importa são tendências, alertas ou decisões relativas à capacidade, é necessário um sistema de monitorização que ordene os pontos de medição cronologicamente, calcule diferenças nos contadores e mantenha valores históricos de comparação. No caso de limites de recursos de serviços ou contentores individuais, uma análise ao nível do cgroup complementa a visão global do anfitrião; o PSI também pode estar disponível por cgroup, se configurado adequadamente.

É necessário ter especial cautela no que diz respeito a /proc/sys. A leitura de um parâmetro serve para fins de diagnóstico; a gravação altera o comportamento ativo do kernel. Altere um valor apenas se a causa for compreendida, o valor inicial tiver sido documentado, os efeitos forem observáveis e houver um caminho de retorno definido. Os diretórios fs, vm e net organizam os parâmetros por temas, mas não fornecem orientações universais para o ajuste.

O exemplo drop_caches mostra a diferença entre intervenção e otimização: a documentação do kernel descreve a interface como não destrutiva, mas alerta para problemas de desempenho e não a recomenda como medida operacional regular fora de cenários de teste ou depuração. Uma regra conservadora é, portanto: primeiro medir, depois efetuar uma alteração fundamentada e limitada, observar os efeitos e os efeitos secundários e documentar a decisão.