Como o swapoff pode ser tão lento?

Question

De alguma forma, aconteceu de eu trocar 14 GB de memória. Depois de ter matado o culpado, eu tenho toneladas de memória livre novamente, então eu pensei que poderia trazer nos dados importantes novamente. Portanto, com 5 GB de 32 GB usados e 14 GB de espaço de troca usados, executei swapoff -a .... e 4 horas depois, cerca de metade do trabalho foi concluído.

Isso significa menos que 1 MB / s, enquanto eu posso copiar facilmente 200 MB / s. Minha troca é criptografada, mas todas as partições normais e com aes-ni não levam a carga da CPU (e preenchem o espaço de troca levou apenas alguns minutos). Eu vejo que não há nenhuma razão especial para otimizar o swapoff , no entanto, eu me pergunto como ele poderia ficar tão lento?

Apenas adicionando mais alguns dados: Minha memória principal é de 32 GB e eu tenho 32 GB de espaço de troca em cada um dos 4 discos rígidos (certamente um exagero, mas quem se importa?). Todo o espaço de troca pode ser (descriptografado e) lido em menos de 5 minutos:

time -p sudo sh -c 'for i in /dev/mapper/cryptswap?; do md5sum $i & done; wait'
014a2b7ef300e11094134785e1d882af  /dev/mapper/cryptswap1
a6d8ef09203c1d8d459109ff93b6627c  /dev/mapper/cryptswap4
05aff81f8d276ddf07cf26619726a405  /dev/mapper/cryptswap3
e7f606449327b9a016e88d46049c0c9a  /dev/mapper/cryptswap2
real 264.27

Ler uma parte de uma partição não pode ser mais lento do que ler tudo. No entanto, ler cerca de 1/10 leva cerca de 100 vezes mais tempo.

Eu observei que durante swapoff a CPU estava praticamente ociosa (talvez 10% de um núcleo) e os discos também ("medidos" pelos LEDs). Eu também vi que os espaços de troca foram desligados um após o outro.

    

Answer 1

Primeiro, vamos ver o que você pode esperar do seu disco rígido. Seu disco rígido pode fazer 200 MB / s sequencialmente . Quando você considera tempos de busca, pode ser muito mais lento. Para escolher um exemplo arbitrário, dê uma olhada nas especificações de um dos modernos discos de 3 TB da Seagate, o ST3000DM001 :

• Taxa máxima de dados sustentados: 210 MB / s

• Pedir média de leitura: < 8.5 ms

• Bytes por setor: 4.096

Se você nunca precisar procurar, e se a sua troca estiver perto da borda do disco, você pode esperar ver a taxa máxima = 210 MB / s

Mas se os seus dados de troca estiverem totalmente fragmentados, no pior cenário, você precisará procurar por todos os setores que você lê. Isso significa que você só consegue ler 4 KB a cada 8,5 ms ou 4 KB / 0,0085 = 470 KB / s

Então, logo de cara, não é inconcebível que você esteja na verdade correndo contra as velocidades do disco rígido.

Dito isso, parece tolo que swapoff seja executado tão lentamente e tenha que ler páginas fora de ordem, especialmente se elas foram escritas rapidamente (o que implica em ordem). Mas isso pode ser apenas como o kernel funciona. O relatório de bugs do Ubuntu # 486666 discute o mesmo problema:

The swap is being removed at speed of 0.5 MB/s, while the
hard drive speed is 60 MB/s;
No other programs are using harddrive a lot, system is not under
high load etc.

Ubuntu 9.10 on quad core.

Swap partition is encrypted.
Top (atop) shows near 100% hard drive usage
  DSK | sdc | busy 88% | read 56 | write 0 | avio 9 ms |
but the device transfer is low (kdesysguard)
  0.4 MiB/s on /dev/sdc reads, and 0 on writes

Uma das respostas foi:

It takes a long time to sort out because it has to rearrange and flush the
memory, as well as go through multiple decrypt cycles, etc. This is quite
normal

O relatório de bug foi fechado sem solução.

O livro de Mel Gorman " Noções básicas sobre o gerenciador de memória virtual do Linux " está um pouco fora de data, mas concorda que esta é uma operação lenta:

The function responsible for deactivating an area is, predictably enough, called sys_swapoff(). This function is mainly concerned with updating the swap_info_struct. The major task of paging in each paged-out page is the responsibility of try_to_unuse() which is extremely expensive.

Há um pouco mais de discussão a partir de 2007 na lista de discussão linux-kernel com o assunto " excesso de velocidade up swapoff "- embora as velocidades que eles estão discutindo sejam um pouco maiores do que você está vendo.

É uma questão interessante que provavelmente é geralmente ignorada, já que swapoff raramente é usado. Acho que, se você realmente quisesse rastreá-lo, o primeiro passo seria tentar observar os padrões de uso de disco com mais cuidado (talvez com atop , iostat ou ferramentas ainda mais poderosas, como perf ou systemtap ). Coisas para procurar podem ser busca excessiva, pequenas operações de E / S, reescrita constante e movimentação de dados, etc.

    

Answer 2

Eu tenho tido o mesmo problema com meu laptop que tem um SSD, portanto, os horários de pesquisa não devem ser um problema.

Eu encontrei uma explicação alternativa . Aqui está um trecho

The way it works now, swapoff looks at each swapped out memory page in the swap partition, and tries to find all the programs that use it. If it can’t find them right away, it will look at the page tables of every program that’s running to find them. In the worst case, it will check all the page tables for every swapped out page in the partition. That’s right–the same page tables get checked over and over again.

Portanto, é um problema do kernel, e não de qualquer outra coisa.

    

Answer 3

Você precisa de uma solução bastante complicada para corrigir o mecanismo swapoff ineficiente.

O one-liner

perl -we 'for('ps -e -o pid,args') { if(m/^ *(\d+) *(.{0,40})/) { $pid=$1; $desc=$2; if(open F, "/proc/$pid/smaps") { while(<F>) { if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ $start_adr=$1; $end_adr=$2; }  elsif(m/^Swap:\s*(\d\d+) *kB/s){ print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" }}}}}' | sort -Vr | head

Isso roda talvez 2 segundos e não faz nada, apenas lista os top 10 segmentos de memória (na verdade, ele imprime mais one-liners; sim, eu faço amor one-liners; apenas examine os comandos, aceite o risco, copie e cole no seu shell; estes irão realmente ler de swap).

...Paste the generated one-liners...
swapoff /your/swap    # much faster now

Algum perigo?

O principal one-liner é seguro (para mim), exceto que ele lê muito / proc.

Os subcomandos preparados para o seu exame manual não são seguros . Cada comando irá travar um processo durante a leitura de um segmento de memória do swap. Por isso, não é seguro com processos que não toleram pausas. As velocidades de transferência que vi foram da ordem de 1 gigabyte por minuto.

Outro perigo é colocar muita pressão de memória no sistema, então verifique com o usual free -m

Mas o que isso faz?

for('ps -e -o pid,args') {

  if(m/^ *(\d+) *(.{0,40})/) { 
    $pid=$1; 
    $desc=$2; 

    if(open F, "/proc/$pid/smaps") { 

      while(<F>) { 

        if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ 
          $start_adr=$1; 
          $end_adr=$2; 
        } elsif( m/^Swap:\s*(\d\d+) *kB/s ){
          print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" 
        }
      }
    }
  }
}

A saída deste script perl é uma série de gdb commands dump memory (range) que recupera as páginas trocadas na memória e incidentalmente torna mais rápido swapoff incrivelmente rápido (vi centenas de MB / s) . A idéia principal de usar o gdb e o smaps vem de esta resposta por jlong .

A saída começa com o tamanho, por isso é fácil passar por | sort -Vr | head para obter os 10 maiores segmentos por tamanho (SSIZE). O -V representa a classificação adequada ao número da versão, mas funciona para o meu propósito. Eu não sabia como fazer um trabalho numérico.

    

Answer 4

Durante o swapoff, se um slot de swap em uso for detectado, então o kernel primeiro troca na página. A função unuse_process () então tenta encontrar todas as entradas da tabela de páginas que correspondem à página apenas trocada e faz a atualização necessária para as tabelas de páginas. A pesquisa é exaustiva e muito demorada: visita cada descritor de memória (de todo o sistema) e examina as entradas da tabela de páginas, uma a uma.

Por favor, consulte a página 724 de "Entendendo a terceira versão do Linux Kernel".