Quando se trata de otimizar o sistema para obter o máximo desempenho, pode ser muito fácil cometer erros se você aplicar imprudentemente as práticas de outras pessoas. Uma dessas práticas é especificar nobarrier ao montar sistemas de arquivos.
Como esta nota nasceu
Eu trabalho como engenheiro na Mail.Ru Cloud Solutions e lida principalmente com todos os tipos de armazenamento em bloco "ao redor e ao redor" nas quais as máquinas virtuais de nossos usuários residem - e, portanto, casos interessantes geralmente surgem relacionados ao desempenho e à estabilidade das máquinas virtuais em execução no aplicativos - e especialmente bancos de dados.
Por via de regra, em quase metade dos casos, quando “interrogamos”, vemos a mesma coisa - um sistema de arquivos montado com a opção nobarrier. E quando perguntamos - “por que você escreveu essa opção”, quase sempre temos uma das opções de resposta “me disseram que era mais rápido / eu li que era mais rápido / fui criado assim” - depois do qual tentamos educadamente e cuidadosamente explicar isso SO não precisa. Porque Porque este é o primeiro passo confiante no caminho para a perda de dados.
Excursão curta
Sistema de arquivos - a estrutura é muito complexa e altamente carregada. Para garantir o desempenho máximo, o cache e a gravação paralela são usados ativamente no processo. Assim, parte dos dados vai para o cache e é descartada sempre que possível / necessário ou "sob demanda". Uma barreira é uma operação especial para forçar todos os caches a serem liberados para o disco.
Quando se trata de bancos de dados, devemos ter certeza de que a transação confirmada para o cliente (aplicativo cliente) foi persistente e não desaparecerá, por um lado, e por outro lado, os DBMSs usam ativamente seu próprio cache para atingir o desempenho máximo - e garantir consistência, o registro no diário é usado - a alteração é gravada no log, o log é “sincronizado” e, em seguida, a alteração é gravada nos dados (e quando é gravada, ela entra no cache). Quando o log está cheio, uma sincronização forçada é feita com todos os dados no cache e o log começa a ser preenchido novamente.
Operação de sincronização
Quando a sincronização é executada, o sistema operacional não apenas libera o cache da página, mas, por padrão, envia um comando para liberar todos os caches de disco (e, possivelmente, faz isso repetidamente) - o chamado
lave . A operação dos buffers de descarga é "cara" e leva uma quantidade considerável de tempo - mas é necessária, pois nos sistemas de arquivos a ordem de gravação é importante - se for violada, (por exemplo) pode acontecer que, durante uma reinicialização repentina do arquivo, haja lixo em vez de dados - desde que o dispositivo decidiu reordenar o registro. E quando a descarga libera à força todos os caches - isso garante que primeiro o que é antes da liberação seja gravado e só depois o que aconteceu depois - ou seja, uma "barreira" seja criada dividindo as entradas em "antes da barreira" e "depois da barreira" (a partir daqui e o nome “barreira de gravação”) - e isso permite garantir que os registros após a barreira não sejam aplicados antes dos registros anteriores à barreira.
Efeito Nobarrier
A opção nobarrier desativa o envio de liberação forçada enquanto o sistema de arquivos está em execução. Isso leva ao fato de que os registros podem ser reordenados - e, se ocorrer uma falha, o sistema de arquivos (e geralmente os dados no caso geral) podem ser inconsistentes - lembremos o que foi mencionado no parágrafo anterior sobre a ordem de gravação.
Por que essa opção está incluída? Para SSDs de baixo custo, a operação de descarga é muito cara - por exemplo, os SSDs de baixo custo (e muitos dispendiosos posicionados como “servidores”) executam de 10 a 20 mil operações de gravação por segundo sem liberação e, com a liberação ativada, caem para 1-2 mil. Nesses casos, o nobarrier fornece um aumento significativo no desempenho, criando os riscos para a integridade dos dados descritos acima.
Ambiente virtual
No caso de uma máquina virtual - se, por exemplo, estamos falando sobre a configuração clássica de máquinas virtuais em um hipervisor Linux, temos o QEMU - um processo que é realmente responsável pela emulação de E / S para o sistema operacional convidado. E o mais importante, se usarmos discos sem backup de arquivo em uma máquina virtual, o cache desse disco virtual (de repente!?) Estará no espaço do usuário - no espaço de endereço do processo QEMU correspondente. E se esse processo travar - por exemplo, de acordo com SEGFAULT / SIGSEGV - todos os seus caches morrerão com ele. Um exemplo desse driver de dispositivo de bloco é o driver RBD (Ceph).
E mesmo que você não use o Ceph, mas o iSCSI / FC, por exemplo, o nível de falha não desaparece - ele simplesmente muda do QEMU para o sistema operacional do host (hipervisor). O hipervisor caiu - o cache da página morreu (isso ocorre para io = 'threads' em combinação com cache = 'writeback' ou cache = 'inseguro'). Opa
s / Cloud / Computador estrangeiro / g
Quando sua máquina virtual é implantada na nuvem ... Então você não sabe como o hypervisor está configurado, como o QEMU está configurado, quais drivers de disco estão envolvidos, se o cache da página do host funciona etc., e você não pode influenciar isso na grande maioria dos casos. E mesmo que seja sua nuvem - onde você sabe tudo isso e mais ou menos a controla, não é fato que seu hipervisor não "caia" - enterrando todo o cache de dados.
Sumário
Usar nobarrier na nuvem significa que você provavelmente colocará seus dados em risco. Tem certeza de que deseja aumentar a produtividade à custa de tais riscos?