Os trabalhos de leitura / gravação podem ser colocados em uma fila?

Question

Eu compartilho um servidor com o HAL. O servidor tem 32 GB de memória.

Eu raramente uso mais de 1 GB de memória, e quando faço isso é por alguns minutos de cada vez, e não me importo de enviar esses trabalhos para o final da linha.

O HAL lê / grava arquivos grandes (por exemplo, usando o gunzip). Isso pode levar até 100% da CPU memória , intermitentemente, por horas. Isso geralmente é feito durante a noite, mas, quando executado, fará com que até mesmo comandos simples, como cd , demorem 30 segundos, abrindo emacs pode levar alguns minutos.

Gostaria de poder reservar 1 GB para uso por processos que usam < < 1GB (como um editor de texto). Eu também gostaria de ficar fora do caminho de HAL, e não vejo razão para que isso seja um problema.

O HAL diz que um sistema de enfileiramento (como o PBS) não pode ser usado para colocar uma prioridade baixa em leitura / gravação, por ex. para deixar 1 GB de memória sempre disponível quando grandes trabalhos estiverem em execução. Em suas palavras:

the script used to gunzip snags all the processors it can because the data is large... queueing would not solve this... during transfer of files from (that server) to (this server), an inflation step does lots of read/write

Por que as filas não puderam resolver esse problema? O que poderia?

    

Answer 1

Você pode ter um sistema de enfileiramento de tarefas ou modificar a abordagem de agendamento do kernel.

Vou ignorar essas opções e sugerir que você use ionice - ou mais especificamente que Bob usa-o para diminuir sua prioridade. Parece que você está tendo um problema de acesso ao disco em vez de um problema de memória.

Regular legal também pode ser uma opção, já que afetará indiretamente a prioridade do disco (a partir da página de manual do ionice: "A prioridade dentro da melhor classe de esforço será derivada dinamicamente do nível legal da CPU do processo: io_priority = (cpu_nice + 20) / 5." ) O software atop também é muito útil para obter uma visão geral do que é a verificação de garrafa e se é IO regular ou a troca para o disco que está em questão.

    

Answer 2

Bob read/writes large files (e.g. using gunzip). This can take up to 100% of the memory, intermittently, for hours. This is usually done overnight, but when running, will make even simple commands such as cd take 30s, opening emacs can take minutes.

Primeiro gzip e gunzip não funcionam da maneira que você acha que eles fazem - o algoritmo usado pelo gzip é baseado em blocos , e embora possa ser um pouco maior quando se passa por um grande o arquivo compactado, mesmo descompactando um arquivo .gz de 1GB, apenas consome cerca de 15M de RAM (tamanho total do processo) na minha máquina.

Segundo, a menos que você esteja sugando o arquivo inteiro para a RAM, simplesmente ler ou escrever um arquivo grande não consome muita memória - O sistema operacional pode armazenar os dados em um cache de sistema de arquivos, mas o cache os dados serão despejados no momento em que um programa precisar dessa RAM. Somente os dados que estão sendo mantidos na memória de trabalho de um programa contam para "pressão de memória" (RAM usada, mais ou menos alguns outros fatores).

I would like to be able to reserve 1GB for use by processes that use << 1GB (like a text editor). I would also like to stay out of Bob's way, and see no reason that this should be an issue.

Pare de tentar enganar o pager de seu sistema operacional: O kernel trocará tarefas para garantir que quem está executando atualmente tenha RAM para trabalhar. Sim, isso significa que você entrará em disco se estiver usando mais RAM do que o disponível. A solução é limitar a quantidade de RAM que você está usando executando menos programas ou para adicionar mais RAM.

O conceito de "reservar" RAM é fundamentalmente defeituoso do ponto de vista do design do sistema operacional: você não poderia ter nenhuma outra atividade em andamento, mas o programa de Bob não pode tocar na RAM "reservada", então agora ele precisa ir e trocar para disco. Por falta de (por exemplo) 1 KB, o programa de Bob agora está fazendo com que o disco constante atinja os dados de paginação dentro e fora da RAM, e seu desempenho passa pelo chão.

Você pode limitar artificialmente o uso de RAM do Bob ( ulimit ), mas quando ele atingir o limite máximo, seus programas provavelmente não reagirão bem (pense: malloc(): Unable to allocate XXXXX bytes seguido por uma saída sem graça).

Você pode, como mencionado no comentário, virtualizar o ambiente e garantir que os processos de Bob tenham acesso apenas aos recursos disponíveis para sua VM, mas isso simplesmente move o problema (a VM de Bob começará a trocar e trocar em uma VM é, por necessidade, ainda mais lento que em metal puro).

No mundo real, Jeff provavelmente está certo - Você provavelmente está atingindo os limites de Disco IO ao invés dos limites de RAM: Descompactar arquivos é uma quantidade enorme de E / S de disco (leia a partir do arquivo compactado). arquivo, passá-lo através da CPU e um pouco de memória RAM, cuspi-lo para o arquivo descompactado). nice (para afetar a prioridade da CPU) e ionice se suportado (para afetar a prioridade do disco) aliviará seu problema.

Palestra

Não é à toa, mas lembro-me da mesma pergunta do meu livro-texto de design do sistema operacional (embora o exemplo não seja gzip / gunzip). Embora haja uma pequena chance de você estar realmente encontrando esse problema no mundo real, tenho minhas dúvidas: é simplesmente um exemplo muito a mais. Lembre-se que Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity - Não é para o dever de casa CS / 301 ( FAQ )

Se este é um problema real do mundo real, peço desculpas - você pode ser o 1 em 10000 que realmente encontrou esse caso de canto em um ambiente de produção.