SQL Azure Engine Throttling
Autor: Marcelo Franceschi de Bianchi – CTS LATAM / Revisor: Roberto Cavalcanti – CTS LATAM
1- Introdução
Para garantir que todos os clientes que estajam utilizando o serviço de banco de dados do SQL Azure recebam um compartilhamento de serviços de forma adequada e evitar que alguns clientes possam monopolizar os recursos do servidor compartilhado, o SQL Azure pode encerrar ou então efetuar o throttle em uma conexão que satisfaz alguns requisitos.
O SQL Azure Engine Throttling continuamente monitora certos limites de performance para avaliar se o sistema continua saudável e pode iniciar vários níveis de throttling a clientes específicos, dependendo de quanto esses clientes estão impactando o sistema.
2- Engine Throttling
Como o próprio nome indica “Engine Throttling” reduz a utilização do consumo de recursos bloqueando a conexão de clientes que estão impactando como um todo à saúde do sistema. O grau de bloqueio da conexão pode variar desde bloqueios a inserts e updates somente, bloqueios em todos os tipos de escritas, ou bloqueio em todas as leituras e escritas.
O tempo de bloqueio é chamado de throttling cycle e a duração dele é conhecida como Throttling Speep Interval que tem como padrão o valor de 10 segundos.
Podem-se ter dois níveis de severidades do throttling, o soft que é aplicado quando o impacto não representa uma ameaça grave ao sistema e o hard quando o impacto é classificado como excessivo e prejudicaria totalmente a performance do sistema. Para o hard throttling exceder os limites de forma que apresenta um grande risco a boa performance, o engine throttling trata de forma agressiva, ou seja, cortando a conexão desses clientes.
O engine throttling segue alguns passos para reduzir a carga e proteger a saúde do sistema:
- Determinar a redução de carga que é necessária para que o sistema possa retornar ao status de saúdavel.
- Marcar como candidatos ao throttling os databases dos clientes que estão consumindo de forma excessiva os recursos do sistema. Se o Engine Throttling estiver ocorrendo por causa de um consumo médio de recursos, então alguns bancos de dados podem ser isentos de serem considerados como candidatos ao throttling. Se o Engine Throttling está executando por causa de um consumo excessivo de recursos, então os bancos de dados podem ser candidatos para o throttling com exceção dos bancos de dados que não receberam qualquer carga no throttling cycle imediatamente anterior ao throttling cycle atual.
- Calcula quantos candidatos a throttling serão efetivamente bloqueados para que o sistema retornar ao status de saúdavel e isso é realizado através da avaliação do histórico baseado no padrão de utilização dos recursos do sistema.
- Então o bloqueio temporário ou o corte de conexão é realizado nos bancos de dados que foram marcados anteriormente como candidatos ao throttling e isso ocorre ciclicamente até que a carga do sistema retorne ao nível considerado com boa performance. Dependendo se o throttling é considerado Hard ou Soft, ou seja, dependendo do grau de classificação poderão acontecer os bloqueios ou então os cortes de conexão e os motivos podem variar de acordo com os Reason Codes. Os bancos de dados que sofreram throttling durante um ciclo de throttling podem permanecer em múltiplos throttling cycles até que o sistema retorne ao estado considerado saúdavel.
3- Limites de performance que são monitorados pelo Engine Throttling
Os limites de performance que são representados por um valor, e o soft limit são calculados através de um percentual desse valor limite e o hard limit é também calculado através de um percentual desse valor limite, logicamente esse valor é maior do que o soft limit e o hard limit só poderá ser iniciado somente quando o valor percentual do soft limit for ultrapassado. Existem alguns limites soft e hard que possuem valores identicos e dessa forma o hard throttling está sendo forçado a ser executado sem passar pelo soft limit.
O Engine Throttling do SQL Azure monitora os seguintes limites:
- DatabaseSpaceUsedPct – Percentual do espaço alocado para o banco de dados SQL Azure que está sem uso, os limites percentuais para soft e hard limit são os mesmos.
- LogSpaceUsedPct – Percentual do espaço alocado para os arquivos de log do SQL Azure que estão em uso. Os arquivos de Log são compartilhados entre os clientes. Os soft e hard limit são diferentes.
- LogWriteIoDelayMS – Millisegundos de atrasos enquanto acontece a escrita para o log drive, os percentuais de soft e hard limit são diferentes.
- DataReadIODelayMS – Milisegundos de atraso quando acontece a leitura dos arquivos de dados, os percentuais de soft e hard limit são os mesmos.
- CPU – Utilização do processador, os soft e hard limits são os mesmos.
- PartitionSizeGB – O tamanho máximo permitido a cada banco de dados individual do cliente, o percentual de soft e hard limits são os mesmos.
- Number OfBusyWorkers – O número total de processos trabalhadores servindo requisições ativas para o banco de dados, o percentual de soft e hard limits são os mesmos. Se o limite é ultrapassado, o criterio para a escolha de qual banco de dados serão bloqueado podem ser diferentes em cada caso se compararmos com os outros limites. Os bancos de dados que estão utilizando o maior numero de processos trabalhadores poderão estar mais sujeitos a serem candidatos ao throttling do que os bancos de dados que estão tendo altas taxas de trafego intenso.
4- Entendendo os erros de throttling
As seguintes mensagens de error podem ser encontradas incluindo o código throttling incident ID.
- 40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.
- 40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: %ls. Code:%d.
- 40545: The service is experiencing a problem that is currently under investigation. Incident ID: %ls. Code:%d.
5- Decifrando o Throttling Incident IDs
O throttling incident ID é um valor que identifica unicamente o throttling que foi aplicado. Se por acaso você receber uma mensagem de erro incluindo Incident ID: %ls, anote esse código e contate o Microsoft Customer Support para investigação. O Microsoft Customer Support irá utilizar esse código para recuperar mais informações relativas ao throttling que foi aplicado. O incident ID pode ser utilizado para recuperar as seguintes informações:
- O inicio do throttling incident
- O tipo de throttling que foi aplicado (soft ou hard)
- O tipo de recurso( por exemplo, CPU) que estava sendo consumido em excesso
- O usuário que estava rodando quando o throttling incident aconteceu.
É importante saber a causa raiz vinda do Suporte, após isso você poderá providenciar as mudanças apropriadas na sua aplicação para evitar que sofra outro throttling novamente.
6- Decodificando os Reason Codes
É importante aprender como decodificar o reason code que é retornado pelo error code 40501 “The service is currently busy. Retry the request after 10 seconds. Code: %d”. O reason code (Code:%d) é um número decimal que contém a informação se o throttling foi soft ou hard e qual era o tipo de recurso que estava sendo consumido em excesso. O throttling mode enumera os tipos rejeitados. O resource type especifica os recursos que foram ultrapassados os limites. O throttling pode acontecer em múltiplos tipos de recursos de forma concorrente, como por exemplo, CPU e IO.
Figura 1: Decodificando os reason codes. (*)
Para o cálculo do throttling mode, é necessário aplicar o módulo por quatro no reason code. A operação modulo retorna o resto de um número dividido pelo outro. Para obter o tipo de throttling e o recurso, então você deverá dividir o reason code por 256 como é mostrado na figura 1 no passo 1. Então converta o resultado em binário como é mostrado no passo 2 e no passo 3. A tabela abaixo lista os tipos de throttling e os recursos.
Código do Throttling mode |
Descrição |
Tipos de statements que são rejeitados |
Statements que continuam processando |
0 |
Sem throttling |
Nenhum |
Tudo |
1 |
Rejeitando Update / Insert |
INSERT, UPDATE, CREATE TABLE , CREATE INDEX |
DELETE, DROP TABLE, DROP INDEX, TRUNCATE |
2 |
Rejeitando todas as escritas |
INSERT, UPDATE, DELETE, CREATE, DROP |
SELECT |
3 |
Rejeitando tudo |
Tudo |
Nenhum |
Tabela 1: Lista dos throttling modes.
Por exemplo, se utilizarmos 131075 como reason code. Para obtermos o throttling mode, devemos aplicar o operador módulo quatro, sendo que temos o resultado 131075 % 4 = 3. O resultado 3 significa que o throttling mode é “Rejeitando tudo”.
Par obter o throttling type e o tipo de recurso, devemos pegar o reason code é dividi-lo por 256. Após isso então devemos converter o resultado para binário. 131075/256 = 512 (decimal) e 10 00 00 00 00 (binário). Isso significa que o banco de dados sofreu throttling por causa de CPU (recurso tipo 4) e o houve hard throttling (10).
7 - Referências
Error Messages (SQL Azure Database)
SQL Azure Connection Management
https://social.technet.microsoft.com/wiki/contents/articles/sql-azure-connection-management.aspx
SQL Azure Connectivity Troubleshooting Guide
Retry Logic for Transient Failures in SQL Azure
SQL Azure Retry Logic Sample
https://code.msdn.microsoft.com/windowsazure/SQL-Azure-Retry-Logic-2d0a8401
Inside SQL Azure
https://social.technet.microsoft.com/wiki/contents/articles/1695.inside-sql-azure.aspx
SQL Server Connection Pooling (ADO.NET)
https://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
* Figura extraída do artigo:
SQL Azure Performance and Elasticity Guide