Estou no Azure! Voltei ao mundo SQL, mas agora estou nas nuvens…

Essa foi minha primeira experiência sobre o SQL Azure. Tudo gira em torno de banco de dados (por que não?), enquanto que o conceito de instância quase desaparece.

Não há comando USE <database>
Não existe TEMPDB
Não existe MSDB, nem SQL Agent
Não existe MODEL, nem administração de arquivos e filegroups

Ainda existe o conceito de tabelas temporárias (#tmp) e variáveis temporárias (@tmp). Mas para aqueles acostumados ao modelo tradicional de banco de dados, a primeira impressão é que tudo está diferente!

Vou começar a investigar as DMV’s e atualizar o blocker script.

Você sabe o que é Lock Convoy? (Dica: não tem nada a ver com os locks e bloqueios do SQL Server).

Já havia presenciado esse problema na faculdade. Fomos fazer um trabalho em grupo com 20 pessoas. A matemática era que, se uma pessoa conseguiria fazer o trabalho em 8 horas, então terminaríamos em questão de minutos ao juntar 20 pessoas. O resultado foi exatamente o oposto. Demoramos mais tempo discutindo a distribuição de tarefa ao invés de fazer a tarefa. Lock convoy!

Esse comportamento chamado LOCK CONVOY ocorre quando várias threads tentam acessar um mesmo recurso e perdem mais tempo do que se fosse apenas por uma thread. Seria algo como uma "escalabilidade negativa" devido ao bloqueio.

Enquanto levantava referências, encontrei outras variações para esse comportamento, como por exemplo: Thundering herd problem (Wikipedia). Lá encontramos uma referência para a ocorrência do problema no Linux.

A discussion of this observation on Linux
https://lkml.org/lkml/2004/5/2/108

Esse problema não é uma exclusividade do Linux. Enfrentamos um problema similar no Kernel do Windows ao trabalhar com uma limitação do dispatcher lock, mas que foi resolvido pelo Arun Kishan.

Arun Kishan
https://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows-Kernel-Dispatcher-Lock/

O problema é minimizado no SQL Server usando uma execução de thread em modo cooperativo.

SQL Scheduler: Cooperative Mode
http://blogs.msdn.com/b/fcatae/archive/2011/03/09/sql-scheduler-cooperative-mode.aspx

Solução (?)

A solução é ser mais rápido (individualmente) ou diminuir o paralelismo. No caso de computadores, podemos usar processadores com clocks mais rápidos. Note que isso é ligeiramente diferente de adicionais mais CPU ou Cores.

No próximo post, vou ilustrar esse comportamento usando um exemplo do nosso cotidiano (pelo menos em São Paulo se aplica quase que diariamente) – o trânsito de carros.

Apesar de trabalhar com SQL Server por um bom tempo, foram raras as ocasiões que falei sobre Alta Disponibilidade no SQL Server. Já tentei ensaiar uma apresentação sobre o assunto, mas acho que não é o meu assunto preferido. A única apresentação que fiz foi sobre o Always On.

Por outro lado, eu sei de uma pessoa que gosta e é expert no assunto: Nilton Pinheiro.

Há algumas semanas recebi um presente dos autores Nilton Pinheiro e do Marcelo Fernandes, que fala sobre os principais conceitos de Failover Cluster Instance (FCI), incluindo a parte de quórum dinâmico.

Não pude deixar de criar um post só para falar que o livro é bem completo. Se você quiser saber tudo sobre Failover Clustering, essa é a referências mais completa que conheço – inclusive, mais do que os livros do Alan Hirt. Os tópicos abordados cobrem desde o básico da instalação e dependências de recursos, mas também fala sobre o Quorum dinâmico (!!!) e Distributed Transaction Coordinator (famoso e incompreendido DTC).

Lembrei de uma pergunta que sempre fazia durante as entrevistas de banco de dados:

Se a leitura de um bloco de 8kb demora 5ms, então quanto tempo demora para ler um bloco de 64kb?

A resposta é simples: 5ms.

Muitas pessoas vão estranhar ouvir que o acesso ao disco não depende do tamanho do bloco. Na verdade, grande parte do tempo é gasto para localizar fisicamente a informação. Uma vez posicionado o cabeçote do disco, o processo de leitura é relativamente rápido e fica na casa dos microssegundos (1000 vezes menor que milissegundo). Isso me lembra os meus primeiros posts do blog:

A mecânica de um Disk Drive
http://blogs.msdn.com/b/fcatae/archive/2009/08/22/a-mec-nica-de-um-disk-drive.aspx

Especificação de Disco
http://blogs.msdn.com/b/fcatae/archive/2009/08/31/especifica-o-de-disco.aspx

Esse é o chamado “tempo de latência”. Tipicamente vemos valores entre 1 a 10ms. Nos ambientes de cloud, observamos latências de até 100ms. Se você tem discos SSD, então terá latência <1ms.

Esse é um conceito muito importante e ainda usado no mundo atual de cloud.

Escrevi o último post sobre o conceito de latência de disco, que é uma das chaves para entender performance no SQL.

Ao invés de falar de latência, podemos calcular o número de operações por segundo. Por exemplo: se a latência de disco é de 1ms, então podemos efetuar 1000 operações/segundo. Se a latência subir para 20ms, então ficamos limitados a 50 operações/segundo. No indústria, costumamos falar IOPS (I/O por segundo) ao invés de operações/segundo.

Disco 7200 RPM – latência de 10ms = 100 IOPS
Disco 10000 RPM – latência de 7.5ms = 133 IOPS
Disco 15000 RPM – latência de 5ms = 175 IOPS
Disco SSD – latência de 0.1ms = 10000 IOPS

Embora o conceito de latência seja mais importante, normalmente falamos sobre a capacidade de IOPS. Note que todos esses números são valores médios e aproximados, podendo variar significativamente dependendo das variáveis (tamanho do bloco, leitura sequencial ou randômica, etc).

Dica: nunca acredite cegamente no material de marketing. Eles sempre utilizam os cenários favoráveis. Que pena que não posso colocar os exemplos aqui… mas existem casos bem enganosos.

Quando queremos criar um banco de dados com alta taxa de escrita, devemos minimizar o tempo de latência na gravação do log. Isso significa que quanto menor o tempo de latência ou maior o IOPS, melhor.

Até agora tratamos latência de disco e IOPS como sinônimos. Mas eles não são!

O tempo de latência depende exclusivamente da mídia onde o dado está armazenado. Por exemplo, não tem como um ambiente com discos magnéticos 15k RPM ter menor latência do que com discos SSD. Entretanto, é possível atingir um maior IOPS com discos magnéticos do que SSD. Pode não ser uma comparação justa, mas basta usar um conjunto com 100 discos magnéticos contra 1 SSD.

Assim, podemos dizer que a equação é IOPS = (1/latência) * (numero de discos).

Quando falamos de cenários de banco de dados, devemos usar as métricas:

Latência: disco de log (operações de escrita)
IOPS: discos de dados (operações de leitura)

É uma mudança sutil, mas engana muita gente!

Como havia comentado no post SQL Azure TempDB, comecei a trabalhar com o SQL Azure. A primeira reação que tive foi que os bancos de dados TempDB, Model e MSDB sumiram.

Hoje quero compartilhar um pouco das outras surpresas que tive com o SQL Azure. Eu não sabia que existem diferentes versões no Azure (11 e 12) e isso faz muita diferença.

Versão 11 ou 12

Como saber qual a versão do SQL Server?

Comecei rodando o comando xp_msver para buscar a versão, mas retornou o erro:

Msg 2812, Level 16, State 62, Line 10
Could not find stored procedure 'xp_msver'.

Então a solução foi rodar SELECT @@version.

Microsoft SQL Azure (RTM) - 11.0.9231.178
Oct 22 2015 12:39:03
Copyright (c) Microsoft Corporation

Hoje estarei trabalhando com o SQL Azure versão 11 e isso é algo muito importante. Muitas coisas não são suportadas pelo SQL 11. Se você é um desenvolvedor, provavelmente notará poucas coisas diferentes. Entretanto, se você for um DBA e está acostumado com o SQL Server tradicional (2000, 2005, 2008, 2012, 2014), então terá inúmeras surpresas.

Documentação

Onde está o SQL Books Online (BOL)? Para mim, BOL é a bíblia do SQL e tem toda a documentação necessária para meu dia a dia. Gosto de fazer o download e deixar instalado na minha máquina, não sendo necessário me conectar online para tirar dúvidas. Mas quando vamos para o Azure, cadê o BOL relacionado?

Books Online
http://technet.microsoft.com/en-us/library/ms130214.aspx

A melhor documentação que encontrei foi o Azure Documentation, mas é bem diferente do BOL.

Azure documentation
https://azure.microsoft.com/pt-br/documentation/articles/sql-database-technical-overview/

Isso não deve ser um problema, pois, na teoria, os comandos tradicionais do SQL funcionam no Azure normalmente.

Comandos Suportados

Na teoria, os comandos tradicionais do SQL funcionam no Azure normalmente. Na prática, quase nada funciona igual ao SQL Server tradicional.

Deixo fazer algumas considerações sobre o cenário:

SQL Azure v11
Comandos administrativos

Meu dia começou com os seguintes comandos:

1. Escolhendo o banco de dados

Não existe o comando USE <database>.

Msg 40508, Level 16, State 1, Line 4
USE statement is not supported to switch between databases. Use a new connection to connect to a different Database.

A forma mais fácil é mudar o contexto de banco de dados usando a interface gráfica. Isso força uma nova conexão com o banco de dados.

O efeito colateral é que a informação sobre o Session ID nunca aparece corretamente. É meio estranho explicar, mas tenho certeza que isso acaba confundindo muita gente (demorei muito tempo para perceber isso).

O ideal é registrar uma conexão e adicionar “Connection Properties” com o nome do banco de dados.

2. Quem está conectado no banco?

Eu raramente uso o comando sp_who. Entretanto, é curioso saber que esse comando não existe no SQL Azure v11. Também não existe sp_who2, nem sysprocesses.

A solução é fácil: basta usar as DMV’s.

3. Qual foi o comando enviado?

Conhecendo os processos ativos no servidor, normalmente quero identificar o comando em execução. Para isso usamos o DBCC INPUTBUFFER para mostrar o conteúdo do último pacote de rede recebido, ou seja, ele contém a informação sobre o que está rodando na máquina. Mas esse é mais um comando não suportado no SQL Azure v11.

Assim, a solução é codificar usando a DMF chamada sys.dm_exec_sql_text.

Uma das vantagens de usar a DMF ao invés do DBCC é a possibilidade de usar dentro de SELECT.

4. Qual o espaço usado pelo banco de dados?

Essa é uma informação fundamental no Azure, pois sempre queremos saber a espaço usado pelo banco de dados. A surpresa é que o clássico sp_spaceused não funciona. Essa procedure depende da sysindexes, que também não existe no SQL Azure v11.

O melhor caminho é usar a DMV sys.dm_db_partition_stats para agregar o número de páginas usadas e reservadas.

Por questão de métrica, calculamos o espaço do banco de dados como 351159 x 8kb = 2743mb.

Conclusão

Ainda estou começando a trabalhar com o SQL Azure e já notei muitas diferenças. Entretanto, essas diferenças não são tão perceptíveis do ponto de vista de desenvolvedor (comandos DML) ou na versão do SQL Azure v12.

Nesses últimos tempos, a Microsoft tem mudado sua própria forma de trabalhar e tem incentivado o Open Source. Tenho percebido isso no meu dia a dia:

Semana passada notei que o Visual Studio Code (@code) tem suporte a sintaxe highlighting do SQL.

Entretanto, isso não foi suficiente para substituir o SQL Server Management Studio (SSMS). Continuo usando todos os scripts e comandos no SSMS, pois ele ainda é imbatível.

Entretanto, tenho usado o VS Code para usar o versionamento do GIT. Agora posso deixar todos os meus scripts disponíveis no GitHub e qualquer um pode baixar e alterar.

https://github.com/fcatae/SQL-Code-Repository

Por fim, esse artigo foi escrito usando o Open Live Writer – que substitui o antigo Live Writer do MSN.

http://openlivewriter.org/

Meu objetivo do post não é mostrar em como a Microsoft é Open Source, mas mostrar que muitas coisas tem mudado a forma de trabalhar (mesmo para aqueles que administram banco de dados SQL Server).

Todo mundo gosta de otimização de performance, por isso, inventei 9 regras para ajudar as pessoas a melhorarem os conhecimentos sobre o assunto. Gostaria de começar falando sobre a Regra 1, que fala sobre monitorar o consumo de recursos.

Logo que escrevi essa regra, pensei em duas coisas:

As pessoas ficarão curiosas para saber por que coloquei a palavra DISK, quando os recursos deveriam incluir CPU, memória e rede.
Ao ler a regra, a expectativa das pessoas será encontrar os contadores do Perfmon ou DMV’s para usar no dia a dia.

Por isso, gostaria de propor o seguinte desafio:

Você é capaz de dizer se o banco de dados está sofrendo lentidão usando somente os contadores do Performance Monitor?

Segue aqui as informações do Performance Monitor:

Processor

%Processor Time = 65%

System

Processor Queue Length = 5
Context Switches/sec = 27000

Logical Disk

Average Disk Queue Length = 13

Memory

%Committed Bytes In Use = 48%
Available MB = 220
Page Faults/sec = 4000

SQL Buffer Manager

Page Life Expectancy = 140
Buffer cache hit ratio = 92%
Lazy Writer/sec = 0.5

SQL General Statistics

User Connections = 5200

SQL Statistics

Batch Requests/sec = 1000
SQL Compilations/sec = 70

No próximo artigo vou comentar um pouco mais sobre a análise do Performance Monitor.

No post anterior, introduzi a primeira das 9 regras para otimização de performance:

Regra 1: Monitorar o consumo de recursos
http://blogs.msdn.com/b/fcatae/archive/2016/01/05/monitore-o-consumo-de-recursos-do-banco-de-dados.aspx

Monitore o consumo: É fácil falar, mas é difícil fazer. Vamos usar como exemplo alguns dos contadores (Perfmon) mais usados pelos DBA:

Processor
- %Processor Time = 65%
Logical Disk
- Average Disk Queue Length = 13
SQL Buffer Manager
- Page Life Expectancy = 140
- Buffer cache hit ratio = 92%
- Lazy Writer/sec = 0.5
SQL General Statistics
- User Connections = 5200

Então, posso tirar algumas (falsas) conclusões:

Consumo de CPU está relativamente alto em torno de 65%, que pode indicar que o processador está ocupado demais
A fila de disco está acima de 2. Isso pode indicar um problema grave de disco
O contador do Page Life Expectancy (PLE) está abaixo de 300, indicando falta de memória.
Buffer cache hit ratio está acima de 90%, revelando que a falta de memória não impacta o sistema
Há um número alto de usuários conectados (5200) e pode estar causando carga no sistema.

Essas são apenas hipóteses baseadas nos valores observados. Esses fatos isolados são podem responder a perguntas do tipo: Preciso comprar mais CPU? Devo adicionar memória ao banco de dados? Será que há muitos usuários conectados? Recomendaria o uso de discos SSD?

Infelizmente não é possível tomar nenhuma ação com esses dados.

Esqueça números, use gráficos

É difícil analisar números frios, por isso, sempre que possível use gráficos. O gráfico revela as oscilações nos indicadores e os dias/horários que houve a mudança. Veja o gráfico a seguir com o contador Page Life Expectancy. Que conclusão temos nesse caso?

Parece que as 10h temos o menor valor.

Note que ainda assim, a análise continua difícil. Posso fazer duas afirmações válidas mas contraditórias:

Está ótimo! O servidor está trabalhando muito bem.
Esse servidor poderia se beneficiar de aumento de memória.

Tudo aqui depende da base de comparação. Se compararmos com os servidores com alta carga, podemos dizer que esse servidor está ótimo (#1). Por outro lado, se compararmos com um servidor tranquilo, poderíamos dizer que o gráfico poderia ser melhor (#2).

Minha opinião é que frequentemente tiramos falsas conclusões do perfmon.

Perfmon: Ferramenta de Baseline

Perfmon é uma ferramenta essencial para monitorar o banco de dados, mas não use como ferramenta primária de troubleshooting.

Como assim? Imagine que o Perfmon seja igual ao medidor de combustível de um carro (de corrida):

Esse medidor é importantíssimo, pois não podemos chegar ao nível zero. Entretanto, é muito difícil determinar o desempenho do carro olhando para esse indicador isoladamente. Pense no Perfmon da mesma forma:

Não use ele para medir performance do sistema
Não considere ele como principal ferramenta de tuning
Não tire conclusões precipitadas com base nele

O correto uso do Perfomance Monitor é fazer “baseline de comparação”:

Estou consumindo mais recurso no mês de janeiro?
Quanto de recurso foi economizado depois das otimizações?
Cheguei no esgotamento de recursos?

Esse foi um exemplo de trabalho de otimização que fiz em um servidor há um tempo:

CPU - ANTES

CPU – DEPOIS

Parece que houve ganhos correto? Agora veja qual foi a redução no acesso ao disco (quanto menor, melhor):

IOPS de Disco – ANTES

IOPS de Disco – DEPOIS

É fácil de fazer comparações usando o Performance Monitor.

Conclusão

Muitas pessoas usam o Perfmon da maneira incorreta, dando o falso sentimento de monitoração.

Não esqueça que o Perfmon é igual ao medidor de combustível. Não deixe o servidor ficar com o tanque vazio. Adicione alertas e monitore por condições críticas. Faça comparações de baseline e procure responder aos seguintes tipos de perguntas:

Estou consumindo mais recurso no mês de janeiro?
Quanto de recurso foi economizado depois das otimizações?
Cheguei ao esgotamento de recursos?

Essa é a forma correta de usa-lo.

No próximo artigo, vou falar sobre os grandes mitos do Performance Monitor.

No post anterior, fiz uma breve introdução sobre o Perfmon. Agora é hora de comentar sobre os principais mitos que sempre as pessoas falam sobre os contadores do Perfmon.

1. Buffer Manager:Buffer Cache Hit Ratio

Buffer Cache Hit Ratio determina a eficiência do cache de memória, sendo que as pessoas recomendam que seja acima de 90%. O cálculo desse contador é baseado nos contadores de Page Lookups/sec e Page Reads/sec, sendo calculado como uma média móvel ao longo do tempo. Esse é um dos contadores favoritos dos DBA’s, embora seja muito enganoso.

Um pouco de matemática:

90% de Buffer Cache Hit Ratio significa 10% de Buffer Cache Miss. Em outras palavras, podemos dizer que 10% das requisições vão para o disco. Um servidor com carga realiza cerca de 100.000 a 1.000.000 de leituras por segundo. Portanto, os 10% de cache miss corresponde a valores entre 10.000 a 100.000 IOPS contra seu storage.

Minha recomendação é que você não use esse contador, mas que use o contador de “Buffer Manager:Page Reads/sec” para saber quantas requisições (em valor absoluto) estão indo ao disco.

Entretanto, se você realmente gosta desse contador, então sempre procure valores acima de 99.5%. Dessa forma, você enxergará um Buffer Cache Hit Ratio de 98% como sendo RUIM; 92% sendo MUITO RUIM; 85% sendo DESASTROSO.

Normalmente quando o servidor está subindo, ele se encontra em processo de warm-up. Durante essa condição, o contador de hit ratio fica extremamente baixo.

2. Average Disk Queue Length e %Disk Busy

Os contadores de fila de disco e porcentagem de uso do disco são os piores indicadores de Performance. Jamais use.

Não existe um valor de mínimo ou máximo

As pessoas falam em 2 vezes o número de spindle, sendo que podemos considerar que os spindles são os discos físicos. Entretanto, o mundo atual de SAN e virtualização impede que esse número seja determinado com precisão. Além disso, os discos montados em LUN podem compartilhar os mesmos arrays de disco com outras LUN – fica inviável determinar qual seria esse valor limite.

Esses contadores fornecem muitos falsos-positivos.

Todos os sistemas de alta performance de disco realizam enfileiramento de disco para aumentar o throughput. Por isso, ao invés de monitorar a fila, é mais importante medir o tempo de latência do storage. A fila é consêquência: quando o storage apresenta alta latência de disco, causa enfileiramento das requisições.

Esses contadores não possuem nenhum significado real. Primeiro, faça a seguinte experiência: colete essas informações do servidor e depois compare os valores. Você notará que os gráficos de %Disk Busy e Average Disk Queue Length são exatamente iguais! Eu diria que o cálculo é mais ou menos o seguinte:

Average Disk Queue Length = IOPS x Latência
%Disk Busy = IOPS x Latência x 100%

O problema desse contador é que ninguém sabe o que isso significa. Se você quiser falar sobre fila com pessoal de storage, então fale sobre “outstanding I/O” e não sobre “Average Disk Queue Length”. Curiosamente, o contador para medir “outstanding I/O” possui um nome muito semelhante: “Current Disk Queue Length”.

No próximo post vou comentar sobre outros contadores do Performance Monitor que não devem ser usados.

No primeiro post da série Os 7 Grandes Mitos do Perfmon, comentei sobre os contadores:

Buffer Manager:Buffer Cache Hit Ratio
LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Agora vamos continuar falando sobre outros contadores

3. Paging File:%Usage

Existe uma discussão sobre qual o tamanho ideal do arquivo de Paging File. Algumas pessoas dizem que o correto é ajustar o Paging File para 1,5 vezes o tamanho da memória da máquina. Entretanto, com as máquinas atuais chegando facilmente a 128GB de RAM, então o arquivo ficaria com quase 200GB de espaço em disco.

A frase de ajustar em 1,5x em relação a memória RAM é um tanto antiquada e deveria se aplicar ao Windows NT e Windows 2000. A realidade mudou bastante com a chegada dos servidores de 64-bits. Hoje podemos dizer que o Paging File deve ser igual ao tamanho ocupado pela Kernel, que seria o tamanho mínimo necessário para gerar um crash dump.

How to determine the appropriate page file size for 64-bit versions of Windows
https://support.microsoft.com/en-us/kb/2860880

Se o tamanho do Paging File não depende do SQL Server, mas da Kernel, então por que monitorar?

Sim, você pode monitorar (temporariamente) esse contador para determinar o valor ideal do paging file – que seria algo entre 2GB a 20GB dependendo da quantidade de memória da máquina. Mas certamente, esse contador de Paging File não vai ajudar em nada no tuning do SQL Server.

Por fim, se o SQL Server estiver usando Paging File, algo está muito errado. O objetivo do banco de dados é usar a memória para fazer o cache dos dados em disco. Usar o paging file (disco) para fazer cache de dados (disco) não faz o menor sentido.

4. Memory: Page Faults/sec e Memory: Pages/sec

Muitos administradores de sistema usam esses contadores para determinar quando há esgotamento de memória do servidor. A memória RAM é distribuída entre os processos do Windows e, quando ficam ociosos, podem ser paginados para o Paging File.

Em um servidor SQL, o comportamento é ligeiramente diferente: quando há falta de memória, o SQL Server inicia o processo de liberação de memória para evitar que os processos sejam paginados para disco. Portanto, a ideia é que o SQL utilize toda a memória disponível na máquina para montar o cache do banco de dados. Se o Sistema Operacional (SO) precisar de memória, então o SQL Server é sinalizado e parte desse cache é desfeito, retornando a memória livre ao SO. Assim, não é necessário verificar se existe paginação de dados com os contadores de Page Faults/sec e Page/sec.

Entretanto, existem motivos mais fortes para evitar esses contadores:

Page Faults/sec – Conhecido também como “soft page faults”, essas paginações ocorrem somente para reposicionar a memória sem a necessidade de ir ao disco. Esse é um processo comum presente em qualquer Sistema Operacional multitasking. A ocorrência de “soft page faults” está mais relacionada a transição de contexto entre processos do que falta de memória.

Portanto, altos valores de Page Faults/sec não correspondem a problemas.

Pages/sec – Conhecido como “hard page faults”, essas paginações são movimentações de dados entre a memória e disco. Esse é um processo muito mais custoso do que o “soft page fault”. A paginação da memória para o Paging File é apenas um dos possíveis causadores de “hard page faults”. Na realidade, qualquer mecanismo de “Memory Mapping” contabiliza como uma operação de movimentação de dados. O problema desse contador é que operações simples como cópia, leitura e gravação de arquivo afetam o “pages/sec”.

Quando há problema de falta de memória, é possível observar um leve aumento nesse contador. Na prática, altos valores de “Memory:Pages/sec” são normalmente gravação do arquivo de Backup ou cópia de arquivo usando o File Explorer.

Partindo do princípio de que o SQL Server não usa Paging File, não recomendo que faça a monitoração de paginação do SO. Entretanto, se você realmente quer diagnosticar algum mecanismo de paginação, então o ideal é monitorar a variação de tamanho do Working Set dos processos.

No próximo artigo, vou comentar sobre os 3 últimos contadores que você deve tomar cuidado.

No primeiro post da série Os 7 Grandes Mitos do Perfmon (Parte 1), comentei sobre os contadores:

Buffer Manager:Buffer Cache Hit Ratio
LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Depois abordei os contadores relacionados ao Paging File (Parte 2):

Paging File:%Usage
Memory: Page Faults/sec e Memory: Pages/sec

Agora vamos terminar com os 3 últimos contadores.

5. SQL Access Methods: Page Splits/sec

O contador Page Splits/sec indica o número de ocorrências de page splits no servidor.

Os registros são armazenados em páginas de 8Kb no servidor. Quando o processo de inserção de registro tenta inserir novos dados, mas não encontra espaço livre na página, então inicia-se o processo de page split. Nesse processo, metade dos registros são movidos para uma nova página, liberando espaço da página original. Após o processo de page split, as páginas envolvidas ficam com 50% de espaço livre e podem continuar o processo de inserção.

Normalmente esse é o contador favorito para iniciar uma conversa sobre “Fill factor”, pois altos números do contador Page splits/sec indicam que as páginas estão frequentemente cheias. Entretanto, o processo de Page Split ocorre naturalmente durante a inserção de dados e não corresponde necessariamente a um problema. Processos de inserção em massa causam sempre um alto número de page splits/sec.

Se realmente for necessário investigar a ocorrência de Page Splits, recomendo que utilize a DMV sys.dm_db_index_operational_stats.

Entretanto, a principal análise é validar os resultados de fragmentação usando a DMF sys.dm_db_index_physical_stats (versão moderna do DBCC SHOWCONTIG).

6. SQL Locks: Lock Waits/sec

O contador de Lock Waits/sec indica quantas sessões entram em bloqueios por segundo. Usar o Perfmon para monitorar os locks é algo que acho interessante na teoria.

Exemplo: Estou no trânsito de São Paulo e de repente começou a chover. Quero monitorar quantas vezes fico bloqueado por algum semáforo usando um contador semelhante ao Lock Waits/sec.

Na prática, isso tem resultados curiosos:

A chuva piorou bastante e não estou andando e ainda não consegui atravessar a avenida. Por isso, o contador Lock Waits/sec indica 0, porque não estou passando por mais nenhum outro semáforo.

O contador de Lock Waits/sec não fornece muita pistas sobre o desempenho do servidor. No geral, esse contador apresenta um valor flutuante e com pouco significado. Em condições de problemas ou de tranquilidade (situações completamente opostas), ele indica zero.

Os demais contadores da família de Lock são confusos. É praticamente impossível conseguir enxergar Number of Deadlock/sec maior do que 1. Lock timeouts possui um nome atrativo, mas geralmente a query sofre timeout (note que lock timeout está associado a @@LOCK_TIMEOUT).

Recomendo que use as DMV sys.dm_os_waiting_tasks e sys.dm_exec_requests para acompanhar os bloqueios. Entretanto, se realmente for importante monitorar os locks usando o Perfmon, então considere o uso do “Lock Wait Time (ms)” e “Average Wait Time (ms)”.

7. SQL General Statistics: User Connections

O contador de “User connection” diz quantas sessões estão conectadas ao servidor. Na realidade, não há nenhum problema em monitorar esse contador, visto que o servidor possui um limite máximo de 30 mil conexões. O problema ocorre quando as pessoas usam esse contador para medir a carga no servidor.

Por exemplo, qual dos servidores está mais sobrecarregado? (a diferença é de 50 vezes!)

Servidor A com 100 conexões
Servidor B com 5000 conexões

Entretanto, a carga depende de quais comandos que estão sendo executados no servidor. Consigo imaginar um usuário chamado DBA, que é capaz de executar um único comando DBCC CHECKDB, e é capaz de causar muito mais carga do que várias aplicações rodando ao mesmo tempo.

Muito semelhante ao User Connections, são os contadores chamados “SQL Statistics: Batch Requests/sec” e “SQLStatistics: SQL Compilations/sec”. O processo de compilação e execução depende muito do tipo de comando submetido. Existem comandos ad-hoc que podem ser facilmente compilados e executados. Por outro lado, existem comandos que acabam com o desempenho da máquina.

Como disse no artigo Perfmon: Falso sentido de monitoração, use o Performance Monitor para criar baselines de comparação do servidor. Houve aumento do número de conexões, batches/seg, números de compilações? Se você quiser saber a verdadeira causa, então abandone (temporariamente) o Perfmon e use a estratégia correta (DMV ou XE).

Finalmente terminamos com a lista dos 7 Grandes Mitos do Performance Monitor.

No próximo artigo, farei a seleção dos contadores do Perfmon que você DEVE usar.

Recapitulando os últimos artigos sobre Performance Monitor.

Artigo: Utilize o Perfmon para criar baselines: Perfmon- Falso Sentido de Monitoração
Artigo: Os 7 Grandes Mitos do Perfmon:
Parte 1: Buffer Cache Hit Ratio, Average Disk Queue Length e %Disk Busy
Parte 2: Paging File:%Usage, Memory: Page Faults/sec e Memory: Pages/sec
Parte 3: SQL Access Methods: Page Splits/sec, SQL Locks: Lock Waits/sec e SQL General Statistics: User Connections

Minha recomendação de contadores do Performance Monitor:

Logical Disk

Avg Disk Sec/Read
Avg Disk Sec/Transfer
Avg Disk Sec/Write
Current Disk Queue Length
Disk Bytes/sec
Disk Read Bytes/sec
Disk Write Bytes/sec
Disk Reads/sec
Disk Transfers/sec
Disk Writes/sec

Memory

%Committed Bytes In Use
Available MB
Committed Bytes
Free System Page Table Entries
Pool Nonpaged Bytes
Pool Paged Bytes

Network Interfaces

Bytes Received/sec
Bytes Sent/sec
Bytes Total/sec

Processor

%Processor Time
%Privileged Time

System

Context Switches/sec
Exception Dispatches/sec
Processor Queue Length
System Calls/sec

Adicionalmente, utilize esses contadores por instância do SQL:

Buffer Manager

Database pages
Free list stalls/sec
Free pages
Lazy writes/sec
Page life expectancy
Page lookups/sec
Page reads/sec
Readahead pages/sec
Stolen pages
Target pages
Total pages

General Statistics

Connection Reset/sec
Logins/sec
Logouts/sec
User Connections

SQL Statistics

Batch Requests/sec
Safe Auto-Params/sec
Forced Parametrizations/sec
SQL Compilations/sec
SQL Re-Compilations/sec

O ideal é fazer coletas com intervalos regulares entre 5 a 60 segundos.

Baseline de Performance

Além disso, os contadores do Performance Monitor são importantes para fazer comparações ao longo do tempo. Eles podem indicar um aumento progressivo do consumo de recursos ou alguma atividade diferente da normal. Utilize esses contadores na forma gráfica para ajudar a identificar algum comportamento diferente.

Existem dois casos nos quais o Perfmon se destaca em relação às demais ferramentas (Profiler, DMV, XE):

Analise a distribuição de memória do SQL Server
Medição dos tempos de resposta do storage

No próximo post, vou colocar um exemplo dos contadores.

Hoje é dia de desafio! Estou colocando os contadores (na forma gráfica) para que você possa analisar e tirar suas conclusões.

Artigo: Perfmon- Falso Sentido de Monitoração
Artigo: Os 7 Grandes Mitos do Perfmon:
Parte 1: Buffer Cache Hit Ratio, Average Disk Queue Length e %Disk Busy
Parte 2: Paging File:%Usage, Memory: Page Faults/sec e Memory: Pages/sec
Parte 3: SQL Access Methods: Page Splits/sec, SQL Locks: Lock Waits/sec e SQL General Statistics: User Connections

Artigo: Contadores do Perfmon

Contadores coletados

Fig.1: Consumo de CPU: %Processor Time e %Privileged Time (Kernel Time)

Fig.2: Fila de CPU: Processor Queue Length

Fig.3: System: Context Switches

Fig.4: Memória: %Committed Bytes

Fig.5: Memória: Available MB (memória livre no sistema)

Fig.6: Logical Disk: Reads/sec e Writes/sec (IOPS)

Fig. 7: Logical Disk: Disk Read Bytes/sec e Disk Write Bytes/sec (taxa de transferência – MB/s)

Fig. 8: Logical Disk: Avg Disk Sec/Transfer (latência do disco)

Fig. 9: Logical Disk: Writes/sec e Disk Write Bytes/sec (IOPS e taxa de escrita no disco de LOG)

Fig. 10: Logical Disk: Avg Disk Sec/Write (latência no disco de LOG) – escala de 0 a 20ms

Fig. 11: Network Interfaces: Data Sent/sec e Data Received/sec (taxa de transferência de rede)

Fig. 12: Buffer Manager: Free Pages, Stolen Pages, Database Pages, Total Pages, Target Pages (Buffer Distribution)

Fig. 13: Buffer Manager: Page Life Expectancy e Lazy Writes/sec

Fig. 14: Buffer Manager: Free List Stalls/sec

Fig. 15: Buffer Manager: Page Reads/sec e Readahead pages/sec

Fig. 16: General Statistics: User Connections

Fig. 17: General Statistics: Logins/sec, Resets/sec e SQL Statistics: Batches/sec

Fig. 18: SQL Statistics: Batches/sec, SQL Compilations/sec, SQL Re-Compilations/sec

Fig. 19: SQL Statistics: SQL Compilations/sec, SQL Re-Compilations/sec, Safe Auto-Params/sec, Forced Parametrizations/sec

Qual a sua recomendação sobre o servidor?

Olhando os gráficos, enxergo pelo menos uma recomendação sobre o servidor. E você, qual a sua opinião?

Falta CPU na máquina?
Falta memória RAM?
Qual o ganho em usar discos SSD?
Podemos habilitar o Buffer Pool Extension?
As stored procedures podem ser otimizadas?
Valeria a pena usar o Hekaton?
Que tal arriscar o ColumnStore?

No próximo post vou revelar um pouco mais sobre como analisar esses contadores. Vamos falar sobre a distribuição de memória do SQL.

O gerenciador de memória de Buffer de dados, também conhecido por Data Cache ou Database Cache, fornece as melhores informações sobre a utilização de memória do banco de dados.

Inicialmente analisamos os contadores:

Page life expectancy
Lazy writes/sec
Free list stalls/sec

Segue aqui alguns exemplos de gráfico do Page Life Expectancy (PLE). Particularmente, gosto de utilizar validar se o PLE está acima de 5000 ao invés de usar o tradicional valor limite de 300. Nos casos abaixo, todos os servidores apresentam carga ao longo do dia, embora apenas o terceiro esteja com aparente falta de memória.

Podemos complementar a análise olhando o contador Free List Stalls/sec, que deve ser sempre zero absoluto – parece que existe um novo Latch que deixa claro sua interferência, que se chama Lazy Writer Helper.

Em seguida, podemos olhar a distribuição de memória usando os contadores:

Database pages
Free pages
Stolen pages
Target pages
Total pages

Os servidores apresentam: 1) distribuição constante e normal; 2) folga e sobra de memória; 3) alto consumo de memória não-buffer (stolen). Em nenhum dos gráficos temos uma situação que podemos chamar de crítica, que seria quando o Stolen Memory chega a 75% do total de memória (pressão interna) ou quando o Total Pages e Target Pages começam a diminuir ao longo do tempo (pressão externa).

Por fim, confirmamos que as variações do PLE são causados por Table/Index Scan no servidor usando os contadores Page Reads/sec e Readahead pages/sec. Adicionalmente, você pode acompanhar o contador Page lookups/sec para ter uma ideia da carga.

Page lookups/sec
Page reads/sec
Readahead pages/sec

Seguem os gráficos correspondentes: notamos que a quantidade de Reads (aleatório + sequencial) é praticamente igual a Readahead (sequencial). Assim, o primeiro servidor apresenta picos de utilização, que causam grandes variações no PLE . No segundo e terceiro servidor, está ocorrendo uma operação de Scan realizando a leitura de 10-30 mil págnas por segundo (equivalente a 80-240MB/seg!!!).

Aqui conseguimos concluir:

Servidor 1 possui memória suficiente para aguendar a carga. A variação do PLE ocorre por conta de picos de consumo (ver gráfico do readahead), mas não há indícios de falta de memória.
Servidor 2 possui memória de sobra (ver o gráfico de Free Memory) e recebe uma carga bastante pesada (ver gráfico de readahead)
Servidor 3 recebe uma carga semelhante ao Servidor 2 (ver gráfico de readahead), entretanto o PLE indica que o nível de memória está constantemente baixo. A distribuição de memória revela que grande parte está reservado como Stolen Memory (provavelmente são Memory Grants). A carga desse servidor é alta e falta memória.

Não há dúvida que o Performance Monitor é a melhor ferramenta para conduzir uma análise sobre a utilização de memória do SQL Server.

Logo que escrevi essa regra, pensei em duas coisas:

As pessoas ficarão curiosas para saber por que coloquei a palavra DISK, quando os recursos deveriam incluir CPU, memória e rede.
Ao ler a regra, a expectativa das pessoas será encontrar os contadores do Perfmon ou DMV’s para usar no dia a dia.

Por isso, gostaria de propor o seguinte desafio:

Você é capaz de dizer se o banco de dados está sofrendo lentidão usando somente os contadores do Performance Monitor?

Segue aqui as informações do Performance Monitor:

Processor

%Processor Time = 65%

System

Processor Queue Length = 5
Context Switches/sec = 27000

Logical Disk

Average Disk Queue Length = 13

Memory

%Committed Bytes In Use = 48%
Available MB = 220
Page Faults/sec = 4000

SQL Buffer Manager

Page Life Expectancy = 140
Buffer cache hit ratio = 92%
Lazy Writer/sec = 0.5

SQL General Statistics

User Connections = 5200

SQL Statistics

Batch Requests/sec = 1000
SQL Compilations/sec = 70

No próximo artigo vou comentar um pouco mais sobre a análise do Performance Monitor.

No post anterior, introduzi a primeira das 9 regras para otimização de performance:

Regra 1: Monitorar o consumo de recursos
http://blogs.msdn.com/b/fcatae/archive/2016/01/05/monitore-o-consumo-de-recursos-do-banco-de-dados.aspx

Monitore o consumo: É fácil falar, mas é difícil fazer. Vamos usar como exemplo alguns dos contadores (Perfmon) mais usados pelos DBA:

Processor
- %Processor Time = 65%
Logical Disk
- Average Disk Queue Length = 13
SQL Buffer Manager
- Page Life Expectancy = 140
- Buffer cache hit ratio = 92%
- Lazy Writer/sec = 0.5
SQL General Statistics
- User Connections = 5200

Então, posso tirar algumas (falsas) conclusões:

Consumo de CPU está relativamente alto em torno de 65%, que pode indicar que o processador está ocupado demais
A fila de disco está acima de 2. Isso pode indicar um problema grave de disco
O contador do Page Life Expectancy (PLE) está abaixo de 300, indicando falta de memória.
Buffer cache hit ratio está acima de 90%, revelando que a falta de memória não impacta o sistema
Há um número alto de usuários conectados (5200) e pode estar causando carga no sistema.

Infelizmente não é possível tomar nenhuma ação com esses dados.

Esqueça números, use gráficos

Parece que as 10h temos o menor valor.

Note que ainda assim, a análise continua difícil. Posso fazer duas afirmações válidas mas contraditórias:

Está ótimo! O servidor está trabalhando muito bem.
Esse servidor poderia se beneficiar de aumento de memória.

Minha opinião é que frequentemente tiramos falsas conclusões do perfmon.

Perfmon: Ferramenta de Baseline

Perfmon é uma ferramenta essencial para monitorar o banco de dados, mas não use como ferramenta primária de troubleshooting.

Como assim? Imagine que o Perfmon seja igual ao medidor de combustível de um carro (de corrida):

Não use ele para medir performance do sistema
Não considere ele como principal ferramenta de tuning
Não tire conclusões precipitadas com base nele

O correto uso do Perfomance Monitor é fazer “baseline de comparação”:

Estou consumindo mais recurso no mês de janeiro?
Quanto de recurso foi economizado depois das otimizações?
Cheguei no esgotamento de recursos?

Esse foi um exemplo de trabalho de otimização que fiz em um servidor há um tempo:

CPU – ANTES

CPU – DEPOIS

Parece que houve ganhos correto? Agora veja qual foi a redução no acesso ao disco (quanto menor, melhor):

IOPS de Disco – ANTES

IOPS de Disco – DEPOIS

É fácil de fazer comparações usando o Performance Monitor.

Conclusão

Muitas pessoas usam o Perfmon da maneira incorreta, dando o falso sentimento de monitoração.

Estou consumindo mais recurso no mês de janeiro?
Quanto de recurso foi economizado depois das otimizações?
Cheguei ao esgotamento de recursos?

Essa é a forma correta de usa-lo.

No próximo artigo, vou falar sobre os grandes mitos do Performance Monitor.

No post anterior, fiz uma breve introdução sobre o Perfmon. Agora é hora de comentar sobre os principais mitos que sempre as pessoas falam sobre os contadores do Perfmon.

1. Buffer Manager:Buffer Cache Hit Ratio

Um pouco de matemática:

90% de Buffer Cache Hit Ratio significa 10% de Buffer Cache Miss. Em outras palavras, podemos dizer que 10% das requisições vão para o disco. Um servidor com carga realiza cerca de 100.000 a 1.000.000 de leituras por segundo. Portanto, os 10% de cache miss corresponde a valores entre 10.000 a 100.000 IOPS contra seu storage.

Minha recomendação é que você não use esse contador, mas que use o contador de “Buffer Manager:Page Reads/sec” para saber quantas requisições (em valor absoluto) estão indo ao disco.

Normalmente quando o servidor está subindo, ele se encontra em processo de warm-up. Durante essa condição, o contador de hit ratio fica extremamente baixo.

2. Average Disk Queue Length e %Disk Busy

Os contadores de fila de disco e porcentagem de uso do disco são os piores indicadores de Performance. Jamais use.

Não existe um valor de mínimo ou máximo

As pessoas falam em 2 vezes o número de spindle, sendo que podemos considerar que os spindles são os discos físicos. Entretanto, o mundo atual de SAN e virtualização impede que esse número seja determinado com precisão. Além disso, os discos montados em LUN podem compartilhar os mesmos arrays de disco com outras LUN – fica inviável determinar qual seria esse valor limite.

Esses contadores fornecem muitos falsos-positivos.

Todos os sistemas de alta performance de disco realizam enfileiramento de disco para aumentar o throughput. Por isso, ao invés de monitorar a fila, é mais importante medir o tempo de latência do storage. A fila é consêquência: quando o storage apresenta alta latência de disco, causa enfileiramento das requisições.

Esses contadores não possuem nenhum significado real. Primeiro, faça a seguinte experiência: colete essas informações do servidor e depois compare os valores. Você notará que os gráficos de %Disk Busy e Average Disk Queue Length são exatamente iguais! Eu diria que o cálculo é mais ou menos o seguinte:

Average Disk Queue Length = IOPS x Latência
%Disk Busy = IOPS x Latência x 100%

No próximo post vou comentar sobre outros contadores do Performance Monitor que não devem ser usados.

No primeiro post da série Os 7 Grandes Mitos do Perfmon, comentei sobre os contadores:

Buffer Manager:Buffer Cache Hit Ratio
LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Agora vamos continuar falando sobre outros contadores

3. Paging File:%Usage

How to determine the appropriate page file size for 64-bit versions of Windows
https://support.microsoft.com/en-us/kb/2860880

Se o tamanho do Paging File não depende do SQL Server, mas da Kernel, então por que monitorar?

4. Memory: Page Faults/sec e Memory: Pages/sec

Entretanto, existem motivos mais fortes para evitar esses contadores:

Page Faults/sec – Conhecido também como “soft page faults”, essas paginações ocorrem somente para reposicionar a memória sem a necessidade de ir ao disco. Esse é um processo comum presente em qualquer Sistema Operacional multitasking. A ocorrência de “soft page faults” está mais relacionada a transição de contexto entre processos do que falta de memória.

Portanto, altos valores de Page Faults/sec não correspondem a problemas.

Pages/sec – Conhecido como “hard page faults”, essas paginações são movimentações de dados entre a memória e disco. Esse é um processo muito mais custoso do que o “soft page fault”. A paginação da memória para o Paging File é apenas um dos possíveis causadores de “hard page faults”. Na realidade, qualquer mecanismo de “Memory Mapping” contabiliza como uma operação de movimentação de dados. O problema desse contador é que operações simples como cópia, leitura e gravação de arquivo afetam o “pages/sec”.

No próximo artigo, vou comentar sobre os 3 últimos contadores que você deve tomar cuidado.

No primeiro post da série Os 7 Grandes Mitos do Perfmon (Parte 1), comentei sobre os contadores:

Buffer Manager:Buffer Cache Hit Ratio
LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Depois abordei os contadores relacionados ao Paging File (Parte 2):

Paging File:%Usage
Memory: Page Faults/sec e Memory: Pages/sec

Agora vamos terminar com os 3 últimos contadores.

5. SQL Access Methods: Page Splits/sec

O contador Page Splits/sec indica o número de ocorrências de page splits no servidor.

Se realmente for necessário investigar a ocorrência de Page Splits, recomendo que utilize a DMV sys.dm_db_index_operational_stats.

Entretanto, a principal análise é validar os resultados de fragmentação usando a DMF sys.dm_db_index_physical_stats (versão moderna do DBCC SHOWCONTIG).

6. SQL Locks: Lock Waits/sec

O contador de Lock Waits/sec indica quantas sessões entram em bloqueios por segundo. Usar o Perfmon para monitorar os locks é algo que acho interessante na teoria.

Exemplo: Estou no trânsito de São Paulo e de repente começou a chover. Quero monitorar quantas vezes fico bloqueado por algum semáforo usando um contador semelhante ao Lock Waits/sec.

Na prática, isso tem resultados curiosos:

A chuva piorou bastante e não estou andando e ainda não consegui atravessar a avenida. Por isso, o contador Lock Waits/sec indica 0, porque não estou passando por mais nenhum outro semáforo.

7. SQL General Statistics: User Connections

Por exemplo, qual dos servidores está mais sobrecarregado? (a diferença é de 50 vezes!)

Servidor A com 100 conexões
Servidor B com 5000 conexões

Finalmente terminamos com a lista dos 7 Grandes Mitos do Performance Monitor.

No próximo artigo, farei a seleção dos contadores do Perfmon que você DEVE usar.