Eu tenho um site que executa um aplicativo muito sensível a IO (Accredo Saturn); é um pacote de contabilidade/CRM escrito em Delphi com um banco de dados local de arquivo simples.
Por vários motivos históricos, o site o estava executando em um servidor de terminal Windows Server 2008 R2 rodando no Server 2012 R2 Hyper-V em um Proliant DL380 G9, com seu DC sendo um antigo DL380 G7 com SBS 2011 (o Exchange está há muito tempo no Office 365 ).
Agora os atualizei para um novo DL380 G10 executando o Server 2019. O host e o controlador de domínio estão rodando em 6x 600 GB 10k SAS em RAID10 (host em sua própria partição, uma partição grande para o resto) em um P408i-p, com o servidor de desktop remoto em 4 SSD SATA de uso misto de 480 GB em RAID10 em um P408i-a. O servidor possui 2x Xeon 4210 e 64 GB de memória. Os dados deste software estão em um VHDX no array SSD, montado diretamente no servidor de desktop remoto.
Eles têm 18 usuários, todos usando o servidor de desktop remoto para este programa, com 8 usuários do call center também usando um agente do sistema telefônico Unify. Um ou dois usam o Edge. Eu pretendia exagerar um pouco nas especificações porque esse cliente é exigente com velocidade e, como mencionei, o software é exigente!
O cliente reclamou da lentidão do software. Eu testei e descobri que uma operação que demorava 5 segundos agora está demorando até 15. A antiga VM 2008 R2 no mesmo hardware está funcionando como sempre, então quase parece ter algo a ver com o convidado .
Executei o diskspd sem nenhum usuário conectado (-c100b -b4K -o32 -F8 -T1b -s8b -W60 -d60 -Sh) e estou vendo IOPS de leitura e taxa de transferência semelhantes em ambas as VMs, mas com algumas grandes variações em threads no nova VM 2019. Estou vendo cerca de 531,41 Mbps e 136 mil IOPS nos convidados, mas dois threads abaixo de 1,9 Mbps na VM de 2019. A VM antiga está em 520,44 Mbps, mas consistentemente em torno de 72-76 por thread, exceto por um thread abaixo de 3,75. O total foi de 133 mil IOPS. Isso está na matriz SSD.
Em comparação, o array SSD bare metal com os mesmos parâmetros está me dando 999 Mbps, consistentemente 124-125 Mbps por thread e um total de 255k IOPS.
Estou há dias investigando isso. Tentei a entrada do registro para desabilitar o balanceador de carga IO, mas sem efeito - não tenho certeza se isso se aplica a 2019. Tentei VHDXs fixos e dinâmicos - até troquei o volume de dados entre servidores (é é seu próprio VHDX). Tentei memória dinâmica e estática. Tentei NUMA ativado e desativado.
Estou perdendo o juízo e tenho um cliente frustrado que está iniciando seu call center do ano na VM antiga amanhã!
O 2008 R2 é uma VM da geração 1, versão 5, enquanto o 2019 é da geração 2, versão 9.
Qualquer dica sobre como recuperar essas IOPS de missão será apreciada!
Este é meu primeiro post, então peço desculpas se não incluí informações relevantes ou específicas suficientes.
Responder1
em 6x 600 GB 10k SAS em RAID10
Instalado em um Raid 1 de 2x SSD de alto desempenho que oferece o que - 50 vezes o IO?
Geralmente: OBTENHA SSD.
Além disso, use SSD de tamanho estático.
Não há muito mais que você PODE fazer - seus números parecem insanos, no entanto. Mais de 200 mil IOPS representam uma programação incrivelmente ruim.
Responder2
Isso não é evidência de que o problema de desempenho se deva ao armazenamento.
Analise detalhadamente o fluxo de trabalho lento do aplicativo.
Quais caminhos de código são necessários? Faça um perfil de quanto tempo cada função leva.
Quais consultas de banco de dados ele faz?
Quantos registros de dados estão envolvidos e em que tamanho?
- Como ele lida com a simultaneidade, incluindo bloqueios baseados em arquivos ou bancos de dados?
- Ele usa algum recurso externo na rede? Qual é a latência para eles?
- Como é a comunicação com o cliente durante a transmissão? O cliente poderia ser o servidor de terminal neste caso.
Provavelmente você precisará da ajuda do fornecedor do software para analisar isso a fundo. Insista em perfis detalhados e visibilidade do tipo que você obteria com um pacote de monitoramento de desempenho de aplicativos.
Limites de recursos como CPU, memória, IOPS, largura de banda da rede podem ser o motivo da lentidão. E essas são métricas a serem medidas. No entanto, também é possível que a pilha desse aplicativo naquele sistema operacional não seja mais rápida, mesmo se você usar hardware nele. A única maneira de saber é isolar o que realmente é lento.
Responder3
Acabei de perceber isso quando vim aqui para pesquisar outro assunto. O problema foi resolvido e ocorreu devido ao disco TSFairShare. Desabilitar isso resolveu o problema - acontece que é um problema para muitos aplicativos que usam um banco de dados em nível de arquivo.
Encontramos a solução enterrada em um fórum do Microsoft Dynamics GP. Os detalhes da correção real estão resumidos aqui -https://www.ryslander.com/disable-fair-sharing-in-windows-server/- para aplicativos como GP e o aplicativo que estávamos usando (Accredo) apenas o FSSDisk precisa ser desabilitado - deixamos os outros em paz.
Observo que com o Server 2022 o padrão voltou a ser desabilitado.