Comprimento da fila de disco de 30 no Serviço de Aplicativo do Azure, que não pode estar certo

Question

Estamos tendo uma batalha com a equipe de suporte do Microsoft Azure. Espero que a comunidade do Serverfault possa falar como a equipe de suporte nos confundiu antes.

Aqui está o que está acontecendo.

Como parte de um serviço SaaS maior que hospedamos no Azure, temos um Serviço de Aplicativo front-end que aceita solicitações HTTP básicas, realiza uma pequena validação e passa o trabalho pesado para um servidor de backend. Esse processo não é intensivo em CPU, memória ou rede e não tocamos no subsistema de disco.

A camada de preços é "Básico: 2 Médio", o que é mais do que suficiente para a carga que colocamos nele. Os gráficos de CPU e memória mostram que o sistema está em grande parte dormindo, com o uso de memória em torno de 36%.

Como prestamos muita atenção na escola dos servidores, monitoramos ativamente as várias camadas da solução geral usando os recursos de monitoramento padrão do Azure. Um dos contadores que acompanhamos é o "Comprimento da fila de disco", é um dos poucos contadores disponíveis no Azure App Services, por isso deve ser importante.

De volta à escola do servidor, foi-nos dito que o comprimento da fila de disco deveria idealmente ser zero e se persistentemente acima de 1, você precisa agir em conjunto (há algumas exceções para certas configurações de RAID). Nos últimos anos tudo estava bem, a duração da fila de disco era zero em 99% do tempo, com um aumento ocasional de 5 quando a Microsoft estava fazendo manutenção no sistema.

Alguns meses atrás, as coisas começaram a mudar inesperadamente (não depois de lançarmos as alterações). Os alertas da fila de discos começaram a ser inundados e o tamanho médio da fila está nos 30s.

Deixamos que ele seja executado por alguns dias para ver se o problema desapareceria (o desempenho não é visivelmente afetado, pelo menos não sob a carga atual). Como o problema não desapareceu, pensamos que talvez o sistema subjacente tivesse um problema, por isso instanciamos um novo Serviço de Aplicativo do Azure e o migramos para esse. O mesmo problema.

Então,entramosemcontatocomosuportedoAzure.Naturalmente,elesnospediramparaexecutarumasériedetestessemsentidonaesperançadequeiríamosembora(elespediramrastreamentosderede...paraumproblemadefiladedisco!).Nósnãodesistimostãofacilmente,entãofizemosseustestessemsentidoe,eventualmente,fomosinstruídosaapenasdefiniroalertaparaotamanhodafilapara50(maisde10minutos).

Emboranãotenhamoscontrolesobreohardwaresubjacente,ainfraestruturaeaconfiguraçãodosistema,issosimplesmentenãoparececorreto.

Arespostacompletaéaseguinte

Ireachedouttoourproductteamwiththeinformationgatheredinthiscase.

TheyinvestigatedtheissueswherethealertyouhavespecifiedforDiskQueueLengthisfiringmorefrequentlythanexpected.

ThisalertissettonotifyyouiftheDiskQueueLengthaverageexceeded10over5minutes.Thismetricistheaveragenumberofbothreadandwriterequeststhatwerequeuedfortheselecteddiskduringthesampleinterval.FortheAzureAppServiceInfrastructurethismetricisdiscussedinthefollowingdocumentationlink:https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor

The value of 10 is very low for any type of application deployed and so you may be seeing false positives. This means the alert might trigger more frequently than the exact number of connections.

For example on each virtual machine we run an Anti-Malware Service to protect the Azure App Service infrastructure. During these times you will see connections made and if the alert is set to a low number it can be triggered.

We did not identify any instance of this Anti-Malware scanning affecting your site availability. Microsoft recommends that you consider increasing the Disk Queue Length metric be set to an average value of at least 50 over 10 minutes.

We believe this value should allow you to continue to monitor your application for performance purposes. It should also be less affected by the Anti-Malware scanning or other connections we run for maintenance purposes.

Alguém quer entrar em contato?

    

Answer 1

Para mim, isso soa muito bem, com o Azure em um ambiente de pool compartilhado. Aposto que seu disco de back-end está sendo martelado por outros clientes. Com base em outros posts, parece que o Azure é conhecido por isso. Gostaria de ver se eles podem realocar seu disco de back-end para um armazenamento menos usado ou tentar as recomendações nessas postagens ou em outras.

Disco de desempenho azul, tamanho médio da fila

desempenho do IO do Azure