Umount é muito lento

Por que é umount tão lento? Por que demora tanto tempo?

write() syscall normalmente escreve em apenas RAM. No Linux chamamos isso de“cache de página” ou “buffer cache”, dependendo do que exatamente o alvo real dowrite() chamada de sistema foi.

A partir desse RAM (cache dentro do sistema operacional, no alto da pilha IO), o sistema operacional não periodicamente fazer writeouts, em seu lazer, a menos que seja instado a escrever peças específicas (ou todo ele) agora.

sync (ou fsync() , ou fdatasync() , ou …) faz exatamente isso: urge o sistema operacional para fazer a escrever.
umount também provoca uma gravação de todos os dados ainda não escrita do sistema de arquivos afetada.

Nota:

  • Claro que a “performance” de gravações que entram em RAM volátil só vai ser muito melhor do que qualquer coisa que vai para estável, persistente, de armazenamento. Todas as coisas que só foram escritos para o cache, mas ainda não sincronizados (escrito para a camada do bloco) será perdido se você tiver uma queda de energia ou falha do servidor.
    A camada de bloco linux nunca viu essas mudanças, DRBD nunca viu essas mudanças, eles não podem, eventualmente, ser replicado em qualquer lugar. 
    Os dados serão perdidos.

Há também caches controlador que pode ou não ser volátil e caches de disco, que normalmente são voláteis. Estes são abaixo e fora do sistema operacional, e não fazem parte desta discussão. Apenas certifique-se de desativar todos os caches voláteis nesse nível.

Agora, por um momento, assumir

  • você não tem DRBD na pilha, e
  • um backend IO moderadamente capaz que escreve, por exemplo, 300 MByte / s, e
  • cerca de 3 GiByte de dados sujos redor no momento em que acionar o umount, e
  • você não buscar-limite, para que o seu backend pode realmente chegar a esse 300 MB / s,

você tem um tempo umount de cerca de 10 segundos.


Ainda assim comigo?

Ok. Agora, introduzir DRBD à sua pilha IO, e adicionar um link de replicação de longa distância. Apenas por uma questão de me tentar explicar isso aqui, vamos supor que porque é de longa distância e você tem um orçamento limitado, você só pode pagar 100 MBit / s. E “longa distância” implica maiores tempos de ida e volta, então vamos supor que temos um RTT de 100 ms.

É claro que iria introduzir um único IO pedido de latência de> 100 ms para nada, mas o protocolo DRBD A, de modo que você optar por protocolo A. (Em outras palavras, usando o protocolo A “máscaras” o RTT do link de replicação do pedido de visível latência.)

Essa foi a latência.

Mas, a largura de banda limitada do que apontam replicação também limita sua taxa de transferência média de escrita sustentada, no exemplo dado para cerca 11MiByte / s.
O mesmo 3 GByte de dados sujos seria agora drenar muito mais lento, no fato de que mesmo umount seria agora tomar e não 10 segundos, mas cinco minutos.

 

Então, concluindo: tentar evitar ter dados muito que não foram salvos na memória RAM, que poderia mordê-lo. Por exemplo, você quer que seu grupo a fazer uma transição, mas o umount leva muito tempo e um tempo limite de acessos: o nó (deve) ficar cercado, e os dados não escritos para o armazenamento estável será perdido.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: