“20.000 IOPS por nó têm bom desempenho com latência de 5 ms.” Para OLTP - não

O motivo para escrever este artigo foi uma revisão muito útil de Como testamos o VMware vSAN ... CROC. A revisão é digna, mas há uma frase com a qual estou lutando há mais de uma década. Administradores de armazenamento, virtualizadores e integradores repetem várias vezes: "Atrasos de 5 ms são um excelente indicador". Mesmo o valor de 5 ms por dez anos não muda. Ouvi isso ao vivo de administradores altamente respeitados, pelo menos uma dúzia de vezes. De menos respeitados - dezenas, e quantas vezes eu li na Internet ... Não, não, não. Para cargas OLTP de 5 ms, principalmente porque geralmente são medidas, são falhas épicas. Eu tive que explicar as razões para isso muitas vezes, desta vez decidi reunir meus pensamentos de forma reutilizável.

Devo dizer imediatamente que não existem tais erros no artigo mencionado acima, mas a frase funcionou como um gatilho.

Início típico

Tudo o que é descrito neste artigo é verdadeiro para DBMSs comuns usados ​​para OLTP comercial típico. Acima de tudo, tenho experiência com o MS SQL Server, mas, pelo menos para o PostgeSQL, Oracle e Sybase, muitos pontos e conclusões também permanecerão verdadeiros.

O DBMS de desempenho geralmente não está satisfeito com todos. Se houver um DBMS em um sistema grande - e de repente ele quase sempre estiver lá -, esse DBMS será um gargalo. Bem, ou ele imediatamente se tornará um gargalo se você começar a otimizar todo o resto. E assim, o cliente chega e diz com uma voz humana: "Socorro! Economize! Eles pagaram $ NNNNNNNN pelo servidor e armazenamento, mas a velocidade não aumenta! Ah, e o administrador configurou e o fornecedor consultou, mas ainda não se move". Se os desenvolvedores do sistema se encaixam na definição de Lavrov (podemos fazer sem uma cotação exata) e os especialistas em operação e manutenção "enfrentam incidentes ao reiniciar o servidor", o problema geralmente é simples e despretensioso: não há índices, consultas distorcidas, erros fatais de configuração (sobre os quais a documentação está em negrito ele diz "você não pode fazer isso !!!" ), bloqueios excessivos, impasses e outras bobagens simples e claras. Existem muitos desses casos, a maioria, mas não todos. Se o sistema, em complexidade ou carga, ultrapassar algum limite invisível, ele morrerá desses problemas ou passará para o próximo nível.

Nesse nível, o servidor não está mais na tabela do diretor, os discos não estão mais dentro do servidor, mas no sistema de armazenamento, os desenvolvedores conhecem os índices e os administradores já conhecem o PowerShell, e os gerentes de TI começam a dizer palavras inteligentes como SLA e RPO / RTO. Uma situação interessante surge neste nível:

• DBMS é um gargalo.
• O servidor parece ser suficiente em todos os aspectos.
• O DBMS pode ser aprimorado ainda mais programaticamente, mas é difícil (alternar para licenças mais caras ou alternar para a "zona vermelha da curva Shipilev" para otimização)
• O sistema de disco é comprado caro e, ao que parece, está de alguma forma configurado.

Mas não. O crocodilo não é capturado, o coco não cresce e o desempenho do sistema é igual ou inferior ao do servidor antigo. Olho em sys.dm_os_waitsats e vejo WRITELOG , PAGEIOLATCH_SH e PAGEIOLATCH_EX na parte superior, o tempo médio de espera é de mais de 5 ms. Bem, típico, cho: "Ei, administradores e DBA, aqui você tem um sistema de disco - gargalo" e aqui começa uma música antiga com cerca de 5 ms:

• Temos 5 ms para SLA
• Sim, temos um regimento de 20.000 IOPS
• O fornecedor nos disse que todos os arquivos de banco de dados podem estar em uma partição
• Temos virtualização e hiperconvergência e não podemos alocar discos separados no banco de dados
• De acordo com nossos dados, a utilização do servidor 5%
• Tudo é configurado de acordo com as recomendações
• Seus bancos de dados não precisam de muito desempenho, não exigem mais de 300 IOPS (e temos uma prateleira para 20.000 IOPS)

A propósito, tudo isso acima, não apenas sobre "seus" servidores, mas também sobre serviços em nuvem e virtualização. Há muitas especificidades próprias, mas o quadro clínico típico é o mesmo: banco de dados moderadamente otimizado, equipe de desenvolvimento e manutenção inteligente, há uma reserva para o processador e a memória, a "exaustão" de novos investimentos é quase zero.

Então aqui. Toda essa música sobre "5 ms" é um absurdo e um absurdo. Se você mesmo diz isso, leia este artigo. E se eles lhe disserem, prepare os argumentos. Antes, quando ouvi essas palavras, fiquei com raiva, mas não estou mais com raiva. Eu, como aquele pote com uma petúnia do Guia do Mochileiro das Galáxias, tenho apenas um pensamento: "Bem, de novo ...".

Quem é o culpado?

Por que o banco de dados é tão lento? Bem, parece que um servidor típico com 20-64 núcleos a uma frequência de 2-3 GHz é capaz de executar 50-150 bilhões de operações simples, e os testes máximos (sintéticos) do banco de dados mostram nessas máquinas apenas 10.000-50000 transações por segundo. Ei! Bem, isso é de um milhão a uma dúzia de milhões de transações possíveis por transação. Não é só muita coisa, é muita coisa para sentir.
Essa sobrecarga custa requisitos de ACID para transações.

• Uma tomicidade - a transação inteira está concluída ou o todo não está concluído.
• C onistância - na entrada e saída de uma transação, o sistema está em um estado consistente
• I solation - as transações não vêem os estados intermediários um do outro
• Durabilidade - se a transação foi concluída com êxito (confirmada), então, independentemente das circunstâncias, as alterações feitas devem permanecer no sistema.

A propósito, letra por letra, esses requisitos não são cumpridos quase em qualquer lugar e nunca, mas simplesmente nunca em sistemas distribuídos (o teorema da PAC interfere). Para nossa situação, é mais provável que o requisito "D" seja mais caro que outros, esse requisito é fornecido pelo mecanismo principal de todos os DBMSs OLTP comuns: WAL, log write-ahead (PostgeSQL), também é um log de transações (SQL Server), também conhecido como REDO log (Oracle). Aqui está - uma pedra no pescoço da produtividade e é a base das transações de Durabilidade.

O que é o WAL?

Vamos esquecer por um momento os SSDs modernos, os sistemas de armazenamento legais. Suponha que tenhamos um servidor, ele tenha um ou mais discos.
Qualquer transação, mesmo a inserção de um registro, é pelo menos potencialmente, mas de fato quase sempre e realisticamente uma ação não atômica. Quase sempre precisamos alterar não apenas a página em que o registro está localizado, mas também as páginas de índice, possivelmente as páginas de serviço. Além disso, na mesma transação, a mesma página pode mudar várias vezes. Além disso, outras transações podem ser realizadas em paralelo conosco. Além disso - as transações vizinhas no tempo constantemente "puxam" as mesmas páginas. Se esperarmos que cada página seja gravada no disco antes de continuar, que é essencialmente o que o Durability exige, teremos que escrever muitas vezes mais e esperar que cada gravação seja concluída em mídia não volátil. Sem caches, sem reorganização das operações na fila, caso contrário, não haverá integridade! Além disso, precisamos observar de alguma forma quais dados já estão em transações fixas e quais ainda não estão (e quais estavam antes). Para entender - um disco rígido único (HDD) típico nesse modo fornecerá 50-100 IOPS e isso é uma constante há 20 anos. Uma transação pequena exigirá 5-10 operações de gravação. Ah, sim, para saber o que gravar, você deve lê-lo. Mesmo sistemas OLTP com muita, muita escrita podem ler 3 vezes mais do que escrevem. Portanto, nossa transação custa 20-40 IO, o que significa 0,2-0,8 segundos por disco.
2 transações por segundo. Não é suficiente? Vamos tentar espalhar os discos? Ah, mas ainda precisamos esperar até que o anterior seja gravado e não haja paralelismo no final. Como ser E vamos começar um arquivo de log no qual gravaremos seqüencialmente todas as operações de gravação no banco de dados e nas marcas de transação! Prós:

• As informações sobre a operação podem ser muito mais compactas do que gravar a página inteira (um tamanho de página típico é 8 KiB, as informações gravadas no log geralmente são 0,5-1 KiB).
• Em vez de escrever sobre se a transação é registrada ou não diretamente na página, há rótulos suficientes sobre o início e a correção da transação no log.
• As páginas não podem ser gravadas após cada transação - várias vezes menos. O processo de leitura / gravação de dados é completamente "desatado" do log.
• A principal coisa. Se colocarmos nosso diário em um disco separado e gravar registros sequencialmente, devido ao fato de você não precisar reposicionar constantemente os cabeçotes de disco, mesmo um HDD doméstico nesse modo comprime até 1000 IOPS, considerando que pequenas transações "custam" de 2 a 4 entradas no diário, então você pode espremer 200-400 TPS
• No caso de uma falha, o estado do arquivo de dados pode ser restaurado usando esse log e, se uma transação for cancelada, as alterações poderão ser revertidas.

Esse log é chamado de log write-ahead / log de transações / log REDO.

Viva! Ótimo! Havia duas transações por segundo, tornou-se 300 - melhorou 150 vezes. E a que custo? Como se vê, o preço é significativo:

• Em todos os DBMSs comuns, o log é estritamente consistente. Um segmento é responsável por gravar no log. Você tem 100 processadores? Legal. E o log ainda gravará um thread. A profundidade da fila é exatamente uma.
• Ainda - sem caches de SO, sem permutações de operações. Os requisitos de durabilidade permaneceram. Operações de gravação: até o disco responder "escrevi, escrevi diretamente na superfície, não no cache, com certeza" O DBMS não continua funcionando.
• Se você colocar o arquivo de log no disco de dados, quase todos os benefícios da gravação seqüencial serão perdidos. Além disso - para sempre, se houver vários bancos de dados no servidor, vários discos para revistas.
• Reversão de transação (pelo menos no MS SQL Server) - leia o log e restaure o estado dele. São tantas ou mais operações de gravação quanto houve operações de gravação na transação. A reversão é cara!

Essa explicação é muito simplificada "nos dedos". Isso é suficiente para o nosso tópico. O WAL é um mecanismo fundamental e fundamental para garantir a transacionalidade, é necessariamente write-through, o acesso é de thread único apenas para gravação sequencial, do ponto de vista do armazenamento, a profundidade da fila é 1.

O tópico do log de gravação antecipada no banco de dados deve ser pelo menos mínimo conhecido por qualquer pessoa que de alguma forma administre o DBMS ou a infraestrutura do DBMS ou desenvolva bancos de dados.

WAL e SHD

Os fabricantes de armazenamento “desde o nascimento” são confrontados com o DBMS. É para bancos de dados que as empresas compram esses complexos insanamente caros: dos armazenamentos de preços de rua da Dell-EMC, HP, Hitachi, NetApp, ao impor um orçamento, os olhos se enchem de lágrimas pela maioria dos gerentes de topo, a menos que, é claro, eles obtenham uma porcentagem desse preço. Mas há um conflito de engenharia e marketing. Explicarei isso usando o Dell-EMC como exemplo, mas apenas porque lembro onde eles têm a documentação.

Então:

1. Diário de encadeamento único
2. O log de gravação, ou seja, latência, é "eterno" comparado ao desempenho da CPU
3. As cargas OLTP são muitas transações relativamente pequenas,
4. A maioria das outras cargas de DBMS são paralelas de uma maneira ou de outra.

A lei da Amdahl impiedosamente nos diz que uma carga de baixo desempenho de thread único tornará a adição de processadores inúteis, e o desempenho será determinado pelo log. Além disso, neste momento, não daremos a mínima para o desempenho do armazenamento no IOPS, e apenas a latência se tornará importante.
Mas não desconte outras operações de disco - leitura e gravação em arquivos de dados e tempdb . A leitura também é uma operação "em espera". Até que uma página de dados seja lida do disco para a memória, o processador não poderá processá-la. Porém, para essas operações, grandes filas e permutações de operações nessa fila são possíveis: o DBMS geralmente sabe quais páginas carregar na memória, quais páginas despejar e coloca muitas filas para leitura de uma só vez. Como nesse cenário é importante quando a última operação do pacote termina, nesse carregamento, pelo contrário, o IOPS é mais importante para nós do que a latência de uma única operação. Para entender o escopo: as operações de leitura em um sistema OLTP típico são de 85% a 95%. Sim, sim, sim, as operações de gravação são uma ordem de magnitude menor.

Os engenheiros de armazenamento de fornecedores estão trabalhando em estreita colaboração com os fornecedores de DBMS e estão bem cientes de todas as nuances técnicas de como um DBMS funciona com um subsistema de disco. O planejamento, o particionamento e a alocação adequados de recursos de disco para o DBMS são uma competência complexa e importante do administrador do sistema de armazenamento . O mesmo Dell-EMC ainda possui o white paper básico H14621 e H12341 para recomendações de particionamento para o SQL Server - mais de cem páginas. Ei! Este não é um encaixe detalhado, é o white paper mais comum! Ainda há muitos específicos ( h15142 , h16389 ... há escuridão lá). Os “adjacentes” do VMware - Arquitetura do Microsoft SQL Server no VMware vSphere não estão muito atrás. Observe que esses documentos não são apenas para os DBAs e não para os administradores de infraestrutura e armazenamento.
Também observo que em todos esses documentos LUNs separados são cortados para dados, logs e tempdb . Sim, em algum lugar nos documentos mais recentes, eles dizem claramente que, para as soluções All-Flash, não faz sentido separar os logs em mídia fisicamente separada, mas os LUNs ainda oferecem cortá-los separadamente. Se você despejar dados e efetuar logon em um LUN, do ponto de vista do sistema operacional, haverá uma fila de E / S. E haverá um problema. As operações de latência terão imediatamente uma ordem de magnitude maior. E devido ao fato de operações de log não realocáveis ​​aparecerem na fila, o IOPS escorregará nos arquivos de dados e no tempdb . Esta não é uma "descoberta do século", é uma verdade elementar do trabalho com o banco de dados. Não está desatualizado ou cancelado com o advento do All-Flash. Sim, os atrasos nas operações com SSDs são mais rápidos em uma ordem de magnitude do que nas operações com HDDs, mas ainda assim algumas ordens de magnitude mais lentas que as operações com memória. O IO ainda é o gargalo do DBMS.
E os documentos técnicos enfatizam corretamente que, nos logs de transações, o número de IOPS não é importante, mas é importante que a latência seja mínima (nos tempos modernos, está escrito que menos de 1 ms).

Mas os profissionais de marketing precisam vender. Hiperconvergência! Virtualização! Flexibilidade de implantação! Desduplicação! Configuração fácil! Muitos, muitos IOPS! Belas apresentações, voz confiante, trajes formais. Mas de que outra forma vender uma solução com um preço de 6 a 7 dígitos em dólares? Por isso, esquece-se de alguma forma que a latência ou a taxa de transferência podem ser obtidas no sistema de armazenamento, mas não de uma só vez, que algum tipo de licença para o balanceador de carga é como outra prateleira, que se a gravação intensiva durar mais de uma hora, a RAM dos controladores não é suficiente e a produtividade diminui para "como se não houvesse cache", que treinar os funcionários do cliente custa outros 100.000 rublos pelo primeiro ano, bem, esses truques ...

5 ms

Ouve falar muito de ter lido profissionais de marketing, ou de preguiça, ou por causa de algum tipo de barata, mas, por algum motivo, os administradores de armazenamento costumam fazer algo assim. Pegamos uma prateleira grande, combinamos tudo em algo plano, cortamos em LUNs provisionadas finas e distribuímos por LUN ao servidor. Ou dois, porque "a partição do sistema está bem desduplicada". E quando vejo que, com o subsistema de disco do lado do SQL, inferno-inferno-inferno, começa a música: "5 ms é um excelente indicador", "100000 IOPS", "Sua carga de armazenamento é inferior a 5%"

NÃO .

• Para sistemas OLTP em uma partição com logs WAL / transação de 5 ms, este é um indicador inválido. No pedaço de ferro "quase comoditizado" por um preço de 1.000 (em palavras: mil) vezes mais barato, o indicador normal agora será de 0,1-0,3 ms. E amanhã - 0,01 ms. Velocidade, como a do HDD de 2008, ao preço de uma entrada inteira de apartamentos em Moscou, não é necessária. Nenhuma "manutenção" vale a pena.
• O fornecedor escreve que os logs de transações não são exigentes no IOPS e podem ser colocados no HDD? É sim. Mas, para isso, é necessário que nenhum desses discos contágio Além de gravar logs, o DBMS não tocou na tarefa. E para que o sistema de armazenamento responda ao servidor que os dados foram gravados, imediatamente quando os dados foram inseridos na memória não volátil (isso é muito mais cedo do que eles serão gravados)
• Discos finos para bancos de dados OLTP reais são ruins.
• Para o WAL, é absolutamente desinteressante a quantidade de IOPS que pode ser extraída por aí a uma profundidade de fila de 10 ou 20. Não há profundidade lá.
• Para o WAL, não é absolutamente um indicador de que a fila de E / S no SO seja "apenas cerca de 1". Ela não será mais.
• Não, os desenvolvedores de DBA e DB não são "pica-paus dobrados que não podem configurar adequadamente para gravar no paralelo WAL" (opinião real do administrador)
• A lógica dos fãs de considerar a reciclagem ", uma vez que o sistema configurado em uma partição tortamente não faz 10.000 IOPS; ele deve ser movido de uma matriz de gama alta para média" - essa é uma lógica incorreta.
• Se o servidor de 40 núcleos tiver uma carga de processador de 2,5%, isso não significa que não há nada a fazer, mas, muito provavelmente, significa que existe algum tipo de tarefa que bloqueia todo mundo.

Quando um carregamento de dados no laptop do desenvolvedor leva 5 minutos, e no 40º servidor nuclear com 1 TiB de RAM e armazenamento por meio milhão de dólares, a mesma tarefa é executada por uma hora, mesmo os clientes mais pacientes terão dúvidas sobre a justificativa dos custos.

O que fazer

Dicas de administrador e DBAs

Para OLTP, pare de contar "reciclagem" e IOPS. Separadamente, observo - não olhe para o IOPS com uma grande profundidade de fila: mesmo nas partições de dados, as grandes filas geralmente têm uma pequena explosão ou algo que não afeta o desempenho real do OLTP.

Compartilhar espaço em disco pelo LUN não é um capricho do DBA. O banco de dados possui vários perfis diferentes de carregamento do subsistema de disco. No mínimo, é possível distinguir o seguinte:

• Trabalhe com arquivos de dados. Normalmente, isso é leitura e escrita com blocos aleatórios de 8/64 KiB. Leituras 80-95%. Filas surgem: durante períodos de serviço, durante períodos de carregamento em massa, em solicitações ineficientes ou em massa e durante o ponto de verificação. O desempenho é afetado pela capacidade de resposta à leitura. É importante que o alinhamento dos blocos 8/64 KiB "passados" passe por todo o sistema de armazenamento.
• Trabalhar com tempdb é o mesmo que trabalhar com arquivos de dados, mas as leituras geralmente são de 40 a 75% e a capacidade de resposta à gravação pode ser importante. Nos modernos sistemas MS SQL, esse banco de dados pode ser carregado várias vezes mais forte que os bancos de dados. Em uma configuração do DBMS não em cluster, esta seção deve ser excluída de qualquer replicação de armazenamento. Seu conteúdo após a reinicialização do serviço ainda será destruído.
• Trabalhe com dados arquivados / DWH. As leituras são próximas de 100%. O tamanho de um bloco de leitura geralmente é de 64 KiB. As solicitações são lidas muito e seguidas, para que a fila possa saltar até 1000 ou mais.
• Trabalhe com logs de transações. A leitura é apenas para manutenção (backup, replicação etc.), o desempenho do aplicativo é afetado apenas pela gravação. Gravação em blocos de 0,5 a 64 KiB. Sem fila, em um thread. O atraso é crítico para aplicativos.
• Backup e restauração. Do ponto de vista do banco de dados, está lendo em grandes blocos (geralmente 1 MiB). É importante que essa carga possa repousar nos canais / barramentos (FC e Ethernet) e no desempenho dos processadores de armazenamento em alguns casos. O backup de um servidor pode afetar o desempenho de outros servidores da mesma SAN / SHD.
• Trabalhar com arquivos de aplicativo: são logs, rastreamento padrão, arquivos binários etc. Essa carga raramente é significativa e é importante apenas no início do sistema.

Existem outros tipos de carregamento, mas eles são um pouco exóticos (por exemplo, pode haver um repositório de arquivos armazenados no banco de dados na forma do diretório FileStream). Todos esses tipos de cargas têm requisitos de disco diferentes, geralmente conflitantes. Se todos eles estiverem empilhados em uma partição, você não apenas prejudicará o desempenho, mas é muito importante perder a capacidade de entender por que o sistema fica mais lento e também perder a oportunidade de melhorar apenas a parte que precisa de aprimoramento sem melhorias / upgrades globais de armazenamento. Portanto, a principal recomendação:

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . Isto está correto. . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

Isso é tudo. . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .