Todo mundo mente: um épico com servidores NVMe e Hi-CPU

É melhor usar o Diskspd ao invés do CrystalDiskMark, pois o código do primeiro na interface com a GUI do segundo dá um bug engraçado.Nós



, em RUVDS, faltava um servidor NVMe na linha para torná-lo mais rápido e poderoso. .. Porque no ano passado a moda passou a implantar em tal Bitrix e 1C ... Há demanda para o serviço, outros serviços de hospedagem também o possuem e são encomendados - em geral, tudo se resumia ao fato de que bastava escolher uma configuração e opções de hardware específicas e comprar em todas as 11 localidades ao redor do mundo. E aqui devo dizer que atualmente suportamos apenas duas configurações: mais rápida e mais lenta. Porque peças de reposição, porque suporte, porque software e assim por diante é uma das partes da política de preços adequados. Ou seja, um terceiro será acrescentado, e aí será possível mudar alguma coisa em quatro anos.



Temos SSD RAID em todos os lugares (mesmo onde o HDD é mostrado com uma tarifa), mas queríamos mais forte, mais alto e mais rápido.



A primeira coisa que aprendemos foi que o NVMe não é combinado em RAID de maneiras normais, ou seja, como resultado, discos confiáveis ​​não devem ser esperados. Em segundo lugar, queríamos colocar o Hi-CPU no mesmo servidor e ficamos surpresos ao descobrir que a frequência de 4,5 GHz não é de servidor, mas o hardware de desktop doméstico e as soluções de servidor com essa frequência simplesmente não existem fisicamente na natureza ainda.



Além disso, no caminho, nosso administrador encontrou um bug fatal no utilitário de teste. Em geral, deixe-me dizer a você com testes como a solução NVMe se parece na hospedagem VDS.



Devo dizer desde já que talvez tenhamos feito algo errado, e se alguém entender isso, ficarei muito grato.

▍ Expectativas de NVMe

Quando mudamos de HDD para SSD, a diferença era como o céu e a terra. Você executa qualquer teste e obtém um aumento de desempenho múltiplo. Este não foi o caso no NVMe. Além disso, em uma colisão frontal com nossas configurações NVMe existentes, as unidades nem sempre as contornavam. Eles foram mais rápidos ou mais lentos, dependendo das condições do teste.



Para começar, compramos algumas opções de servidor. Normalmente compramos uma plataforma, testamos, entendemos o que há de errado, testamos novamente e então a implementamos em 11 locais, porque muitas peças sobressalentes de uma vez e novos processos de suporte são caros. Então, compramos uma plataforma e imediatamente deparamos com um resultado incrivelmente ruim.



No mesmo hipervisor em diferentes sistemas operacionais convidados, era impossível distinguir entre SSD dentro do servidor ou NVMe. Até com a massa.



Ao usar NVMe em RAID, a velocidade será mais lenta do que SSD. A grosso modo, quando usamos RAID, nós o incluímos em um barramento PCIe e ficamos limitados a este PCI Express, e podemos paralelizar apenas alguns discos em barramentos diferentes. Precisamos de controladores.



Por que assim, ninguém poderia dar uma resposta normal. Eles perguntaram a um antigo fornecedor confiável, a novos fornecedores e, em geral, a fornecedores de esquerda. Todos deram de ombros e disseram: "Bem, vocês geralmente otários, que colocam NVMe em RAID - não haverá desempenho!". A redação era diferente da fornecida, mas o significado permaneceu inalterado. Então, percebemos que provavelmente deveríamos usar o NVMe sem um ataque. Existe uma empresa (um concorrente amigável) - então, apenas eles explicaram que tinham a mesma coisa há alguns anos. Eles jogaram fora várias plataformas e, no final, decidiu-se não usar o RAID.



Ou seja, o primeiro problema é que quando o disco for lançado, não haverá autorebuild para um novo, que será trazido pelo administrador. Sem RAID, os clientes perderão o status e os dados da máquina virtual. Não é a mesma coisa, mas estamos tentando seguir em frente.



Então, há uma escolha entre U2 e M2. Compramos jantes U2 caras. Eles estão presos pela interface Okulinka no barramento. M2 é mais frequentemente usado em desktops, eles grudam na placa-mãe. Nós também testamos, não há muita diferença entre eles. Mas se o disco estiver preso diretamente na placa sem uma interface intermediária, será mais difícil fazer a manutenção - em caso de falha, você terá que remover a tampa do servidor e remexer.

▍ Agora os testes são a realidade do NVMe

O resultado depende do sistema operacional host, da versão do hipervisor, da versão do sistema operacional doméstico na máquina virtual e da escolha do método de teste.



Depende do fato de que os hipervisores mais recentes suportam NVMe com seus drivers nativamente, enquanto outros funcionam como uma sobrecarga de SSD. Este também não é um resultado muito bom, porque estamos habituados a utilizar soluções comprovadas. Existe um servidor Windows 12-16-19. Usamos a versão máxima 16. Quando a próxima for lançada, usaremos a 19. Porque as versões mais recentes são sempre beta. Em geral, apenas geeks e suicidas usam a versão mais recente do software na administração do servidor. E sim, se sua mão está tremendo agora, você é um geek. Ou um testador beta. Embora você possa não saber ainda. O fornecedor do software lança regularmente uma nova versão, dá reinicializações, atualizações, patches - você precisa passar por uma geração para que funcione de forma estável. Como sempre, estamos aguardando o segundo service pack. Você não pode explicar a um cliente sobre uma nova vulnerabilidade ou um novo pacote de atualizações da MS. Mais precisamente,podemos explicar, mas o cliente nem sempre acredita. Com a nossa frota de carros no 19º Windu, não é muito bom andar. Se todos os servidores começarem a fazer música colorida com atualizações e reinicializações, você não vai querer bater na sua cara.



O segundo ponto importante diz respeito à estranheza no arquivo de 45 GB, você verá agora.

Metodologia: durante o teste, usamos o utilitário diskspd . CrystalDiskMark foi parafusado em torno dele , que queria usar em primeiro lugar, mas encontramos um bug muito engraçado.



É importante para nós que ambas as concessionárias:

• Permite que você especifique vários arquivos de teste ao mesmo tempo. Além disso, esses arquivos podem estar localizados em discos diferentes. Isso pode ser útil para verificar a taxa de transferência geral do controlador ao ler independentemente em discos diferentes. Número de processos. Quantos threads independentes um do outro serão criados para ler e gravar arquivos.
• Em diskspd, número de solicitações de IO pendentes por thread - pode haver algumas discrepâncias na tradução. Além disso, no CrystalDiskMark esse parâmetro é chamado de Queue, embora dificilmente possa ser chamado de fila.

▍ Compreender o número de parâmetros IO pendentes

Para entender como o utilitário funciona, podemos examinar seu código-fonte. As linhas a seguir são muito interessantes.



Para ler:

 if (useCompletionRoutines)
{
    rslt = ReadFileEx(...);
}
else
{
    rslt = ReadFile(...);
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

E linhas semelhantes para escrever:

if (useCompletionRoutines)
{
    rslt = WriteFileEx(...);
}
else
{
    rslt = WriteFile(...);
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Argumentos omitidos para maior clareza. Estamos mais interessados ​​no fato de que a leitura e a gravação são realizadas pelas funções WinAPI padrão:



ReadFile

WriteFile



E as funções assíncronas correspondentes:



ReadFileEx

WriteFileEx



Se você olhar mais de perto o código, poderá entender o seguinte:



Ao definir o número de pendentes IO = 1 , as opções síncronas ReadFile e WriteFile serão usadas. O pseudocódigo para a operação de gravação é assim:

void testThreadFunc() {
	while (!stopTesting) {
		WriteFile(...) //   
      }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Se você definir o número de IO pendentes> 1 , as opções ReadFileEx e WriteFileEx assíncronas serão usadas, e o número de IO pendentes definirá a profundidade de tais chamadas para cada thread. O pseudocódigo para uma operação de gravação com número de IO = 3 pendentes é assim:

void callback1() {
	while (!stopTesting) {
		WriteFileEx(..., callback1)
      }
}

void callback2() {
	while (!stopTesting) {
		WriteFileEx(..., callback2)
      }
}

void callback3() {
	while (!stopTesting) {
		WriteFileEx(..., callback3)
      }
}

void testThreadFunc() {
	WriteFileEx(..., callback1) //    
	WriteFileEx(..., callback2) //    
	WriteFileEx(..., callback3) //    

	//     
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Portanto, o número de IO pendentes é o número de chamadas assíncronas em cada thread.

▍ Por que não usamos CrystalDiskMark

O utilitário CrystalDiskMark é apenas um frontend gráfico para diskspd . É fácil adivinhar sobre isso se você instalar o utilitário e acessar o diretório CdmResource \ DiskSpd.







Mas existem vários problemas com a implementação desse shell.



Primeiro, ele modifica o código diskspd de alguma forma . É fácil de entender se você olhar o código CrystalDiskMark:

command.Format(L"\"%s\" %s -d%d -A%d -L \"%s\"", ..., GetCurrentProcessId(), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ao chamar diskspd, é passado o parâmetro -A com o Id do processo atual. Diskspd não tem esse parâmetro. O autor de CrystalDiskMark decidiu não analisar a saída do console diskspd e decidiu obter os dados de uma maneira mais complicada. Além disso, o método escolhido não é o mais bem-sucedido.



Nesta função, diskspd é chamado diretamente :

int ExecAndWait(TCHAR *pszCmd, BOOL bNoWindow, double *latency)
{
	DWORD Code = 0;
	…
	GetExitCodeProcess(pi.hProcess, &Code);
	*latency = (double)*pMemory * 1000; // milli sec to micro sec
	return Code;
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Em princípio, não há dúvidas sobre a transferência de latência por meio da memória compartilhada . Mas se considerarmos mais a fundo o código onde o valor da variável Code é usado , fica claro que esta é a velocidade do disco medida. Não é uma boa ideia retorná-lo por meio do ErrorCode do processo. Por exemplo, se o processo terminar com um erro por algum outro motivo, o código do erro será simplesmente exibido como resultado do teste.



Também existem dúvidas sobre a exatidão do valor de retorno da latência . Ao especificar a opção -L, diskspd retorna algo assim:





Por exemplo, a sexta linha significa que 95% do tempo a latência será inferior a 54,306 ms . O CrystalDiskMark simplesmente retorna a média de todos os valores da tabela. Isso pode ser enganoso.

▍ Parâmetros de teste

Para ver os benefícios do NVME, você precisa definir o número de E / S pendentes grande o suficiente. Escolhemos o número 32.



❒ Plataforma:



Supermicro SuperServer SYS-6029P-WTRT 2U



❒ Unidades:



Intel SSD DC P4610 Series 1.6 TB, 2,5 pol PCIe 3.1 x4, 3D2, TLC



❒ Comandos para executar diskspd para arquivo 10G:

DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c10G G:/testfile.dat
DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c10G G:/testfile.dat
DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c10G G:/testfile.dat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

❒ Comandos para executar diskspd para arquivo 50G:

DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c50G G:/testfile.dat
DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c50G G:/testfile.dat
DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c50G G:/testfile.dat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

▍ Resultados

❒ Tabela 1 SO host do Windows Server 2019



❒ Tabela 1 SO Windows Server 2016 Host



No Hyper-V e em um convidado do Windows Server, os resultados são difíceis de explicar. Em um pequeno arquivo de cerca de 10G, obtemos um grande aumento no IOPS em comparação com um SSD em um ataque. Mas se pegarmos um arquivo 45G , ao contrário, teremos uma queda significativa no IOPS.

▍ Agora no Hi-CPU

A segunda surpresa abriu em processadores de 4,5 GHz.



Deve ser dito aqui que os processadores nas linhas de servidor também são usados ​​pela geração -1 do desktop. Porque os testadores beta são jogadores e você pode enviar patches de software para eles. Mas nos servidores, até mesmo o mesmo heartblade não foi corrigido imediatamente, e nem tudo. Todas as soluções de servidor são confiáveis ​​e caras, mas sempre são inferiores em velocidade.



Temos tarefas não relacionadas à área de trabalho. A máquina está dividida entre vários clientes. E agora vemos configurações em 4,5 GHz, que não são da natureza.



Acontece que existem duas implementações:

• Hi-CPU ( , ). , , . .
• , turbo boost-, . ! - 3,6 4,5 . , -, : . ( ), . .

▍

Como resultado, decidimos permanecer nos nossos comprovados 3,6 GHz (turbo boost de 4,4 GHz) e, assim, fechar a pesquisa com o processador.



Com o NVMe - tendo obtido resultados aleatórios de um utilitário super padrão, como você pode ver, mudamos a ferramenta. Em seguida, vem a questão do hipervisor e do sistema operacional.



Comercialmente, esses discos oferecem cada vez mais, você tem que aprender a trabalhar. Para nós, deixamos uma certa combinação da versão host do hipervisor e continuaremos a testar, apresentar os discos também. Se um hoster escreve NVMe, isso não significa nada ainda. No KVM com certas montagens * nix novas e configuração meticulosa, você pode obter ganhos excelentes, mas cada teste deve ser marcado com um asterisco - “em tais condições, se você mudar um pouco, e em geral tudo não é assim”. No 12º Windows ou Debian, tudo é diferente.



Em geral, NVMe é um padrão incondicional, mas até agora isso não significa que definitivamente será mais rápido com ele. Estamos implantando servidores com ele com cuidado, mas desde que o ganho corresponda aproximadamente ao aumento no preço, não há mágica.