Por que o kswapd0 está sendo executado em um computador sem troca?

Eu tenho um servidor em nuvem com ~ 14G de RAM e sem troca. No entanto, ocasionalmente vejo o kswapd0 ocupando uma CPU quando executo top. Por que o kswapd0 estaria em execução se não havia espaço de troca para ele gerenciar?

Ele ainda tem um processo para verificar se há alguma troca. Para reduzi-lo, você precisará definir sua permuta -

edite "/etc/sysctl.conf" como root e altere (ou adicione)

vm.swappiness = 0

O espaço de troca é usado apenas para dados que não são suportados por nenhum outro arquivo. Os dados mapeados de outros arquivos no disco (como programas executáveis) ainda são trocados pelos respectivos arquivos, mesmo que você não tenha um dispositivo de troca.

É um problema bem conhecido que, quando o Linux fica sem memória, ele pode entrar em loop de troca em vez de fazer o que deveria estar fazendo, eliminando processos para liberar memória RAM. Há um assassino de OOM (falta de memória) que faz isso, mas apenas se Swap e RAM estiverem cheios.

No entanto, isso realmente não deve ser um problema. Se houver vários processos ofensivos, por exemplo, Firefox e Chrome, cada um com guias que estão usando e capturando memória, esses processos causarão a troca de leitura. O Linux entra então em um loop em que a mesma memória está sendo movida para frente e para trás entre a memória e o disco rígido. Por sua vez, isso causa inversão de prioridade, quando a troca de alguns processos para frente e para trás faz com que o sistema não responda.

Se você desabilitar a troca, você piorará esse problema, pois o kswapd0 agora não tem outra opção do que trocar a memória mapeada, como executáveis. Se você trocar os executáveis, é ainda mais provável que eles sejam trocados novamente rapidamente.

Tentei desencadear esse comportamento no NetBSD para teste e o que aconteceu foi que o processo ofensivo se tornou incrivelmente lento enquanto o próprio sistema operacional era muito responsivo. Significando que o problema de troca ocorre, mas não há inversão de prioridade. No entanto, o NetBSD não possui drivers AMDGPU, por isso estou aderindo ao Linux por enquanto. Talvez o NetBSD não execute executáveis ​​de mapeamento de memória e é por isso que ele não entra em loop de troca, mas eu realmente não sei o suficiente sobre sua implementação para dizer por que não deixa de responder.

O Facebook também teve esse problema e criou o OOMD, que é o Daemon Out Of Memory. Este é o daemon que detecta a atividade kswapd0 e inicia os processos de interrupção. E, de acordo com o Facebook, isso quase eliminou completamente o problema de os servidores Linux deixarem de responder. No entanto, eu não testei e não sei se ele funcionará em outros servidores ou desktops / laptops. OOMD possui alguma lógica para decidir quais processos matar primeiro, a fim de preservar os processos do sistema e a parte do sistema do servidor responsável por reiniciar o que foi morto.

No entanto, não é assim que deve ser resolvido. OOMD é um HACK FEIO. A solução real é corrigir a inversão de prioridade que um loop de troca causa, além de tornar o OOM Killer do kernel mais agressivo na eliminação de processos para liberar memória. A correção pertence ao kernel porque é o único local em que podemos ter certeza de que o problema é detectado a tempo e que os processos estão sendo devidamente eliminados.

Definir swappiness = 0 não é solução, porque quando o sistema está sem RAM livre, ele começa a trocar, não importa o quê. Não há opção para garantir que o sistema não comece a trocar.

E também corrigir os aplicativos incorretos não é uma correção. Especialmente se um usuário quiser explorar esse bug para intencionalmente deixar o sistema operacional sem resposta. Ser responsivo é responsabilidade do kernel. Se o Firefox não responder, a correção é para o aplicativo. No entanto, ele não está apenas respondendo, mas fazendo com que todo o sistema operacional fique muito lento e sem resposta. No nível em que pode levar meia hora para efetuar login no SSH. O SSH não tem nada a ver com isso e, se não for executado, é um bug no kernel, não em nenhuma outra parte do sistema. E não é um bug, são dois bugs. Um bug é a inversão de prioridade, em que um ciclo de troca fora dos trilhos pode interferir com outros processos que não o (s) processo (s) ofensivo (s) e que por si só é ruim. O outro bug é que ele não • Detecte que ele está em um loop de troca e causa desgaste insano no HDD / SSD ou em qualquer armazenamento que esteja apoiando a troca. Ao trocar o executável, isso é menos problemático, pois eles são mapas de memória somente leitura que não são gravados de volta em discos, mas o kswapd0 ainda fica bloqueado lendo de volta o que ao mesmo tempo está excluindo da memória.

Ah, e há um terceiro bug. O fato de que não há como impedir que o CACHE do disco seja consumido quando aplicativos com fome de memória engolem toda a memória disponível. Essa é uma das razões pelas quais o kswapd0 deixa o sistema sem resposta. Os dados mais quentes da memória mapeada geralmente são armazenados no cache do disco, mas quando o Firefox o consumiu, obviamente significa que as leituras do disco deverão ocorrer.

Não é necessariamente o Firefox que está causando seu problema, mas é o navegador padrão, não o Chrome. E ambos são amplamente conhecidos por desencadear esse problema, pois tratam a memória disponível como algo desperdiçado, incluindo memória cache e swap, que no Linux conta como "memória disponível". Portanto, para não obter a "memória disponível" desperdiçada, use-a para armazenar em cache e outras coisas. Obviamente, usar SWAP para DISK CACHE é uma IDEIA MUITO RUIM, mas os colegas do Firefox e do Chrome respondem a isso com "memória livre é memória desperdiçada".

Então, o que temos aqui são três bugs do kernel que a equipe do kernel não parece considerar bugs. E um bug no Firefox, Chrome e todos os derivados que eles não consideram um bug. Tentei criar o Firefox no meu laptop Fedora para analisar esse problema e talvez corrigi-lo. Adivinha. Construir o Firefox com GCC em uma CPU de 4 núcleos com 4 GB de RAM aciona um LOAP SWAP com INVERSÃO PRIORITÁRIA. Portanto, um dos aplicativos que precisa ser reescrito é o GCC. No NetBSD, o que acontece é que apenas as 4 instâncias em execução do GCC ficam mais lentas que a execução em uma instância, mas não congela o sistema.

Sim, isso é meio que divertido, mas espero que esclareça o problema atual com os subsistemas de memória Linux, bem como com os aplicativos que o causam.

Se você não tem permuta e kswapd0está em execução, seu sistema está realmente usando quase toda a RAM naquele momento. É hora de obter ferramentas melhores para monitorar o uso da memória (ou a memória disponível / livre no sistema).

A correção real é reduzir o uso de memória (executar processos com menos vazamentos de memória, executar menos processos, ignorar a execução de alguns processos, limitar o número de processos filhos / trabalhadores de algum software de servidor) ou obter mais RAM. Se a necessidade de RAM for causada por vazamentos de memória, você poderá optar por usar a troca. O Linux deve ser bastante inteligente para trocar as partes vazadas, com tempo suficiente. Ter swap é melhor que nada, mas isso não é um substituto real da quantidade adequada de RAM.