Posso distinguir entre latência de swap e não-troca de alta latência de IO de alguma forma?

Question

Meu sistema se torna muito, muito menos responsivo, toda vez que clona uma imagem de VM. Estou usando virt-manager e posso ver que o IO é executado por vários qemu-img convert threads.

Eu tentei coletar algumas informações, e parecia que poderia ter sido muita troca (E / S na partição swap). Eu tenho 8GB de RAM e 2GB de swap. Durante e após o clone, free -h mostrou que 100% do espaço de troca foi usado. No entanto, isso não me diz quanto o sistema estava trocando no momento. Alguma coisa pode ter preenchido a troca antes de clonar a VM.

Estou usando um disco rígido giratório. Meu sistema operacional atual é o Fedora Linux 28.

Como posso estar preparado quando isso acontece, para reunir as informações relevantes e ver se há muita troca ou não?

Eu quero algum tipo de registro que eu possa analisar e coletar informações diferentes. Ou seja se eu executar um comando simples top ou iotop , eles sobrescreverão sua saída antiga; Eu não quero isso.

    

Answer 1

Eu tenho atop instalado, com uma solução alternativa para que funcione corretamente quando suspendo meu sistema (um laptop) durante a noite .

Os atop logs podem ser muito informativos, se você tiver um problema prolongado com o consumo de memória. A frequência de amostragem (padrão) é de 10 minutos, portanto, pode perder problemas mais curtos.

• O meu problema parece ter durado 10 a 20 minutos.
• O uso de swap aumentou de 1,4G na amostra anterior para 2G (100%).
• Os próprios tópicos qemu-img não tinham um tamanho grande na RAM. O processo qemu-img tinha apenas 25 milhões de residentes.
• swout foi 175735 . Isso é medido em páginas de 4096 bytes, o que significa que 0.7G foi trocado.

Ao mesmo tempo, cache cresceu de 0,8G para 2,3G. free de memória ficou em 0,1G.

Eu suspeito qemu-img está fazendo IO em cache, o cache está empurrando outra memória, e isso é o que causa a troca. Se eu não tivesse espaço de troca, espero que ainda haja algum problema; isto é, o código do programa carregado e outros caches seriam despejados.

Parece que meu qemu-img convert é mais complexo que cp e está criando muitas páginas "ativas" no cache.

One could think of the inactive list as a sort of probational status for pages that kernel isn't sure are worth keeping. Pages can get there from the active list as described above, but there's another way to inactive status as well: file-backed pages, when they are faulted in, are placed in the inactive list. It is quite common that a process will only access a file's contents once; requiring a second access before moving file-backed pages to the active list lets the kernel get rid of single-use data relatively quickly.

https://lwn.net/Articles/495543/

Se eu drop_caches e, em seguida, cp um arquivo 16G, pareço ter um problema semelhante, onde ele aciona bastante troca. Então o kernel não parece estar se livrando dos dados de uso único tão rapidamente quanto eu esperava.