Por que os sistemas ficam lentos ao fazer gravações em massa no disco?

Quero saber por que os sistemas ficam lentos ao gravar dados em massa no disco.

Eu acho que para o sistema ficar lento, deve haver algum problema com a CPU. Mas a gravação é apenas ligada à E / S.

As interrupções de hardware ocorrem ao gravar dados? Nesse caso, pode ser por causa das interrupções que a CPU está sempre alternando o contexto.

A principal razão por trás disso é que o habitual: a E / S é muito mais lenta que a CPU / RAM. Mesmo que os processos que executam operações de E / S usem DMA (que descarrega a CPU), em algum momento eles provavelmente precisarão aguardar a conclusão de suas solicitações.

No caso mais comum de um disco rígido, basta adicionar vários aplicativos que tentam acessar arquivos espalhados pela unidade e você pode tomar um café (chá, qualquer que seja). Com os SSDs, a situação melhora, mas mesmo um SSD - com taxa de transferência medida em centenas de MB / s no SATA (em comparação com dezenas de MB / s de um disco rígido giratório) e tempos de busca realmente insignificantes (comparado a milissegundos para um prato giratório) - pode se tornar um gargalo.

O problema que eu entendo não está apenas nas transferências de dados, mas na sobrecarga necessária - a E / S é controlada pelo kernel, mas raramente acontece sem o espaço do usuário. Portanto, pode haver muitas opções de contexto, apenas a partir das aplicações que aguardam a E / S, verificando se algo está acontecendo (depende da implementação, é claro). No caso de transferências de disco, pode haver vários threads do kernel competindo por recursos ou aguardando ocupado (o que às vezes é a estratégia apropriada). Lembre-se, por exemplo, copiar dados de uma partição para outra requer um sistema de arquivos moderno para: descobrir onde estão os dados de origem, ler, alocar espaço no sistema de arquivos de destino, gravar metadados, gravar dados e repetir até terminar.

E se, em algum momento, seu sistema começar a trocar (que geralmente tem prioridade mais alta que a E / S comum), o desastre será finalizado.

EDIT : Depois de conversar com alguns desenvolvedores de kernel do Linux, a situação ficou um pouco mais clara. O principal problema é o planejador de E / S, que não tem muita idéia sobre qual E / S priorizar. Portanto, qualquer entrada do usuário e a seguinte saída gráfica está compartilhando a fila com a atividade do disco / rede. Como conseqüência disso, também pode acontecer que ele jogue fora os dados do processo em cache do cache da página (por exemplo, bibliotecas carregadas) quando concluir que pode usar o cache da página com mais eficiência em outras E / S. É claro que isso significa que, uma vez que esse código precise ser executado novamente, ele precisará ser buscado novamente - forme o disco que já pode estar sob carga pesada.

Dito isto, no que diz respeito ao kernel do Linux, muitos desses problemas foram corrigidos recentemente (o problema é conhecido), por exemplo, o 4.4.x ou 4.5.x deve se comportar melhor do que costumava e os problemas devem ser relatados (geralmente as pessoas do kernel ficam felizes quando alguém quer ajudar com relatórios e testes de bugs).

Minha experiência é que a atividade de E / S por si só não diminui a velocidade do sistema. Esse efeito ocorre quando outras tarefas também precisam de E / S. A situação se tornará realmente ruim se o sistema estiver trocando (forçado a) e você causar uma carga pesada de E / S.

Você pode influenciar o impacto da I tarefas de E / S pesadas por ionice. Se você os idlepriorizar, a latência para outras tarefas ainda poderá aumentar, mas não além do mínimo. A tarefa de E / S é interrompida imediatamente se outra tarefa (não ociosa) tiver E / S para executar. Se você estiver usando um agendador que suporte essas configurações.

Consulte Selecionando um agendador de E / S do Linux