O sistema fica lento ao executar grandes operações de R / W nos discos externos

Question

Estou tendo alguns problemas com latência / atraso de todo o sistema ao executar operações de criação de imagens em disco grandes em um sistema Ubuntu 18.04. Aqui estão as especificações do sistema:

Processador: Intel Core i7 (nunca perto da capacidade em qualquer núcleo)

Memória: 12 GB (nunca perto da capacidade)

Disco do sistema: SSD (nunca perto da capacidade)

Discos externos: discos giratórios USB 3.0 de 5400 e 7200 RPM

Essas grandes operações de criação de imagens de disco são basicamente:

nice ionice dd if=/dev/usbdisk1 of=/dev/usbdisk2

Como nenhum dos meus arquivos de sistema está em nenhum disco USB, em teoria, isso não deve introduzir muita latência. Mas eu acho que quando estou visualizando mais de um disco USB, o sistema só fica rastreado. Por quê? Meu entendimento é que cada disco tem sua própria fila de E / S, então o que está acontecendo aqui? Como posso remediar isso?

Além disso, FWIW, eu não me importo com a velocidade de geração de imagens dos discos USB, então as soluções que retardam essas operações em favor do sistema funcionando sem problemas são excelentes para mim.

    

Answer 1

How can I remedy it?

Quando você gravar imagem de disco, use apenas dd com oflag=direct . As gravações O_DIRECT evitarão gravar os dados por meio do cache de páginas. Nota oflag=direct exigirá um tamanho de bloco maior para obter um bom desempenho. Aqui está um exemplo:

dd if=/dev/usbdisk1 of=/dev/usbdisk2 oflag=direct bs=32M status=progress

NOTA: às vezes você pode querer enviar uma imagem de disco de outro programa, como gunzip . Nesse caso, o bom desempenho também depende de iflag=fullblock e da passagem por outro comando dd . Há um exemplo completo na resposta aqui: Por que um gunzip para pipeline dd desacelera no final?

(Uma solução alternativa é usar oflag=sync em vez de oflag=direct . Isso funciona por não construir muitas páginas de cache não escritas ).

My understanding is that each disk has its own IO queue, so what's going on here?

Eles fazem. O problema é o cache da página do sistema. Existe apenas um cache de páginas.

Quando um programa precisa ler ou gravar uma página de arquivo que não está na memória ou alocar uma nova página de memória, pode ser necessário remover uma página "inativa" do cache de páginas. Para despejar uma página que contém dados não gravados, você deve primeiro gravar os dados no disco.

Tecnicamente, o número de páginas não escritas ou "sujas" é limitado a uma certa proporção de sua memória. Eu suponho que isso limita o que o problema deve afetar. Mas uma vez que este limite sujo é atingido, um write pode parar para que outras páginas sejam escritas. Mesmo se você tivesse alguma memória que ficou totalmente sem uso!

Os sintomas e o limite de sujeira são descritos em O problema pernicioso da paralisação da USB (LWN.net, 2013).

Há outra tentativa de explicar o problema no 4º comentário neste post de blog de 2017 . Para resumir: o cache de páginas atua como uma fila de write-back compartilhada inicial.

(Veja também a pergunta Limite o tamanho do cache de gravação para um determinado dispositivo? . Infelizmente, isso não parece ser possível.)

Havia também o que parecia como um artigo LWN de acompanhamento em 2016, chamado "Toward writeback de fundo menos irritante". No entanto, acredito que isso não se aplica a você, então você ainda precisa de oflag=direct . É discutido aqui: É "write-back" afogamento "uma solução para o" problema de barramento de pendrive USB "? )