Em relação à virtualização do SQL Server, estou tentando encontrar informações se houver um impacto positivo no desempenho ao separar os dispositivos de dados dos dispositivos de log em diferentes adaptadores Paravirtual SCSI (PVSCSI), semelhante ao que é feito aqui .
Houve um cenário em um cliente em que um PVSCSI adicional foi adicionado e os dispositivos de log foram separados para o novo PVSCSI, mostrando ganhos de desempenho consideráveis. No entanto, permanece a dúvida se foi devido a essa separação ou simplesmente devido ao fato de que um PVSCSI adicional agora estava presente.
Como se sabe, os discos de Log são normalmente gravados de maneira sequencial, enquanto os discos de Dados seguem um padrão mais aleatório em seu r/w, e há benefícios de desempenho ao colocar esses dois tipos diferentes de arquivos em discos separados.
Mas e os controladores? Existe um benefício também em manter esses padrões diferentes em controladores PVSCSI separados?
Alguém tem alguma visão sobre isso?
desde já, obrigado
Vou responder em duas partes: primeiro "por que a resposta tradicional sobre a separação sequencial e aleatória geralmente não se aplica."
Em seguida, discutirei os benefícios potenciais de separar arquivos no disco físico do Windows e adicionar vHBAs adicionais e distribuir os discos físicos entre eles.
Esperar o benefício da separação de E/S de disco aleatório e sequencial no nível do disco físico do Windows normalmente pressupõe dispositivos HDD para o armazenamento de dados. Ele também normalmente assume que discos físicos separados do Windows significam dispositivos HDD separados. A ideia é que algum conjunto de HDDs está lidando principalmente com IO de disco sequencial e tem movimento de cabeça de disco muito limitado (por exemplo, os HDDs hospedando um único txlog* ocupado) enquanto um conjunto separado de HDDs está lidando com IO de disco aleatório.
Essas suposições raramente são válidas hoje - especialmente em uma VM. Em primeiro lugar, a menos que os discos físicos do Windows das VMs sejam RDMs, vários deles podem estar em um único armazenamento de dados - ou talvez vários armazenamentos de dados estejam em um único host ESXi LUN. Portanto, o que está separado no convidado pode ser misturado no nível do host ESXi.
Mas digamos que RDMs sejam usados ou que cada disco físico convidado esteja em seu próprio armazenamento de dados, em seu próprio ESXi LUN. Mesmo assim, o io sequencial separado do aleatório no convidado geralmente é misturado na matriz, porque os LUNs apresentados ao host ESXi podem ser do mesmo pool único de dispositivos de disco. Quase todos os arrays de armazenamento fazem isso agora - exclusivamente ou como uma opção para facilitar o gerenciamento e aumentar a eficiência do array/utilização de recursos.
Finalmente, muito do armazenamento hoje é totalmente flash ou flash híbrido + HDD. Sem nenhum movimento de cabeça para se preocupar, o flash não se importa com a separação de sequencial para aleatório... nem mesmo se preocupa com a tecelagem de IO.
Então… essas são todas as razões pelas quais separar o sequencial do aleatório pode não ser tão benéfico. Em seguida, por que espalhar arquivos em discos físicos e espalhar discos físicos em vHBAs ainda pode aumentar o desempenho de qualquer maneira.
*Mencionei propositalmente um único log de transação neste exemplo de HDD. Quando vários fluxos de E/S de disco sequencial separados (por exemplo, 8 logs de transações ocupados) estão ocorrendo nos mesmos HDDs - a menos que quase toda a atividade esteja dentro do cache SAN - o movimento constante da cabeça entre as trilhas de E/S sequenciais leva à tecelagem de E/S. Esse é um tipo específico de batida na cabeça do disco que leva à latência do disco que é "pior que aleatória". Acontece no RAID5 e no RAID10, embora o RAID10 possa tolerar um pouco mais de variação a esse respeito do que o RAID5 antes da degradação significativa.
Agora - dada aquela longa conversa sobre como separar sequencial de aleatório pode não ajudar - como espalhar arquivos em discos físicos ainda ajuda? Como a distribuição de discos físicos entre vHBAs pode ajudar?
É tudo sobre filas de E/S de disco.
Qualquer disco físico ou disco lógico do Windows pode ter até 255 IOs de disco pendentes por vez, o que é relatado pelo perfmon como "Fila de disco atual". Dos IOs de disco pendentes na fila de disco físico, o storport pode passar até 254 para o minidriver. Mas o minidriver também pode ter uma fila de serviço (passada para o próximo nível inferior) e uma fila de espera. E storport pode ser instruído a diminuir o número que passa de 254.
Em um convidado VMware Windows, o driver pvscsi tem uma profundidade de fila de "dispositivo" padrão de 64, onde o dispositivo é um disco físico. Portanto, embora o perfmon possa mostrar até 255 IOs de disco em "comprimento da fila de disco atual" para um único disco físico, apenas até 64 deles seriam passados para o próximo nível por vez (a menos que os padrões sejam alterados).
Quantos IOs de disco podem ser pendentes para umlog de transação ocupado de cada vez? Bem, as gravações do log de transações podem ter até 60 KB de tamanho. Durante um ETL de alta escala, geralmente vejo cada gravação no txlog em 60kb. O gravador de txlog pode ter até 32 gravações de 60kb pendentes em um txlog por vez. E se eu tiver um txlog de preparação ocupado e um dw txlog ocupado no mesmo disco físico, com as configurações padrão do VMware? Se ambos os txlogs estiverem atingindo o máximo de 32 gravações pendentes de 60 kb cada, esse disco físico está em sua profundidade de fila de 64. Agora… e se também houver arquivos simples como uma fonte ETL no disco físico? Bem… entre as leituras dos flatfiles e as gravações do txlog, eles teriam que usar a fila de espera, porque apenas 64 podem sair por vez. Para bancos de dados com txlogs ocupados assim, seja servidor físico ou virtual, recomendo o txlog em seu próprio disco físico, sem mais nada no disco físico. Isso evita o enfileiramento nesse nível e também elimina qualquer preocupação com o conteúdo de vários arquivos intercalados (o que é uma preocupação muito, muito menor atualmente).
Quantas E/S de disco podem ser pendentes para um arquivo de linha por vez (da perspectiva do SQL Server, não necessariamente submetidas a níveis inferiores)? Não há realmente um limite no próprio SQL Server (que eu encontrei, de qualquer maneira). Mas supondo que o arquivo esteja em um único disco físico do Windows (não recomendo usar discos dinâmicos distribuídos para SQL Server, isso é assunto para outra hora), há um limite. É o 255 que mencionei antes.
Com a mágica do SQL Server readahead e IO assíncrono, eu vi 4 consultas simultâneas, cada uma executando na unidade serial, um total de "comprimento da fila de disco atual" de mais de 1200! Por causa do limite de 255, isso nem é possível com todo o conteúdo do arquivo de linha em um único disco físico. Foi contra um grupo de arquivos primário com 8 arquivos, cada um em seu próprio disco físico.
Portanto, as leituras de readahead podem ser muito agressivas e podem sobrecarregar as filas de E/S. Eles podem ser tão agressivos que outras leituras e gravações de arquivos de linha acabam esperando. Se os logs de transações estiverem no mesmo disco físico que os arquivos de linha, durante leituras simultâneas de leitura antecipada e gravações de txlog, é muito fácil esperar. Mesmo que essa espera não esteja no nível de "comprimento da fila do disco atual", ela pode estar esperando na fila do dispositivo (64 por padrão com pvscsi).
As leituras de backup em arquivos de linha também podem ser agressivas, especialmente se a contagem de buffer tiver sido ajustada para maximizar a taxa de transferência de backup.
Há mais um tipo io do SQL Server a ser considerado ao considerar o isolamento de txlogs: query spill to tempdb. Quando o derramamento de consulta ocorre, cada trabalho derramado grava no tempdb. Tem muitos trabalhadores paralelos derramando ao mesmo tempo? Isso pode ser uma carga de gravação e tanto. Manter um txlog ocupado e arquivos de linha importantes longe disso pode ser realmente útil :-)
Agora, é possível alterar a profundidade da fila do dispositivo padrão para o driver pvscsi. O padrão é 64 e pode ser definido como 254, que é o máximo que o storport transmitirá. Mas tenha cuidado ao mudar isso. Eu sempre recomendo alinhar a profundidade da fila do dispositivo convidado com a profundidade da fila LUN do host ESXi subjacente. E definir a profundidade da fila de LUN do host ESXi por práticas recomendadas de array. Usando um EMC VNX? A profundidade da fila do LUN do host deve ser 32. O convidado usa RDMs? Excelente. Defina a profundidade da fila do dispositivo pvscsi convidado como 32 para que fique alinhada com a profundidade da fila LUN do host ESXi. EMC VMAX? Normalmente 64 no nível do host ESXi, 64 no convidado. Pure/Xtremio/IBM FlashSystem? Às vezes, a profundidade da fila de LUN do host será definida como 256! Vá em frente e defina a profundidade da fila do dispositivo pvscsi para 254 (máximo possível).
Aqui está um link com instruções. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
O link também fala sobre requestringpages - WhatAreThose?? Eles determinam a profundidade da fila para o próprio adaptador pvscsi. Cada página fornece 32 slots na profundidade da fila do adaptador. Por padrão, requestringpages é 8 para uma profundidade de fila de adaptador de 256. Ele pode ser definido como 32 para 1024 slots de profundidade de fila de adaptador.
Digamos que tudo esteja no padrão. Eu tenho 8 discos físicos com arquivos de linha neles e o SQL Server está levemente ocupado. Há uma média de 32 "comprimento da fila de disco atual" nos 8, e nenhum é maior que 64 (tudo se encaixa nas várias filas de serviço do dispositivo). Ótimo - isso dá 256 OIO. Ele cabe nas filas de serviço do dispositivo, cabe na fila de serviço do adaptador para que todos os 256 saiam do convidado para as filas no nível do host ESX.
Mas… se as coisas ficarem um pouco mais ocupadas, então uma média de 64 com a fila de alguns discos físicos de até 128. Para aqueles dispositivos com mais de 64 pendentes, o excesso está em uma fila de espera. Se houver mais de 256 na fila de serviço dos dispositivos nos 8 discos físicos, o excedente ficará em uma fila de espera até que os slots na fila de serviço do adaptador sejam abertos.
Nesse caso, adicionar outro pvscsi vHBA e espalhar os discos físicos entre eles dobra a profundidade total da fila do adaptador para 512. Mais io podem ser passados do convidado para o host ao mesmo tempo.
Algo semelhante pode ser alcançado permanecendo em um adaptador pvscsi e aumentando requestringpages. Ir para 16 renderia 512 slots e 32 renderia 1024 slots.
Quando possível, recomendo ampliar (adicionar adaptadores) antes de aprofundar (aumentar a profundidade da fila de adaptadores). Mas… em muitos dos sistemas mais ocupados, é preciso fazer as duas coisas: colocar 4 vHBAs no convidado e aumentar as páginas de solicitação para 32.
Há muitas outras considerações também. Coisas como sioc e otimização de profundidade de fila adaptável se vmdks forem usados, configuração de caminhos múltiplos, configuração do adaptador ESXi além da profundidade de fila LUN, etc.
Mas não quero prolongar minhas boas-vindas :-)
Lonny Niederstadt @sqL_handLe