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:

  1. Determinar a redução de carga que é necessária para que o sistema possa retornar ao status de saúdavel.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. LogWriteIoDelayMS – Millisegundos de atrasos enquanto acontece a escrita para o log drive, os percentuais de soft e hard limit são diferentes.
  4. DataReadIODelayMS – Milisegundos de atraso quando acontece a leitura dos arquivos de dados, os percentuais de soft e hard limit são os mesmos.
  5. CPU – Utilização do processador, os soft e hard limits são os mesmos.
  6. 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.
  7. 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.

image

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)

http://msdn.microsoft.com/en-us/library/windowsazure/4cff491e-9359-4454-bd7c-fb72c4c452ca#bkmk_throt_errors

SQL Azure Connection Management

http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-connection-management.aspx

SQL Azure Connectivity Troubleshooting Guide

http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-connectivity-troubleshooting-guide.aspx

Retry Logic for Transient Failures in SQL Azure

http://social.technet.microsoft.com/wiki/contents/articles/4235.retry-logic-for-transient-failures-in-sql-azure.aspx

SQL Azure Retry Logic Sample

http://code.msdn.microsoft.com/windowsazure/SQL-Azure-Retry-Logic-2d0a8401

Inside SQL Azure

http://social.technet.microsoft.com/wiki/contents/articles/1695.inside-sql-azure.aspx

SQL Server Connection Pooling (ADO.NET)

http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

* Figura extraída do artigo:

SQL Azure Performance and Elasticity Guide

http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-performance-and-elasticity-guide.aspx