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.

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.

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.

O serviço de Active Directory Federation Service nunca esteve tão em evidência como nestes últimos anos devido à adoção de serviços na nuvem pelas empresas. Conectoar a identidade do Active Directory onpremises com serviços na nuvem pode ser uma desafio. Diferente dos protocolos NTLM e Kerberos que não foram desenvolvidos para a Internet o ADFS atua como um provedor de identidade para a aplicações web suportado os principais protocolos de comunicação com aplicações modernas.

O ADFS 3.0 suporta três protocolos de sign-in:

WS-Federation

• Desenvolvido por um grupo de empresas, incluindo Microsoft;
• Utilizado para integração com a plataforma .NET e produtos Microsoft (SharePoint, Azure, Dynamics CRM);
• Token no formato SAML 1.1;
• Mais informações em https://msdn.microsoft.com/en-us/library/ms951235.aspx e https://msdn.microsoft.com/en-us/library/bb498017.aspx.

SAML-P

• Desenvolvido por um comitê técnico do OASIS;
• Sigla de Security Assertion Markup Language (Linguagem de Marcação de Assertivas de Segurança);
• Padrão para intercâmbio de informações de autenticação e autorização entre diferentes domínios de segurança;
• Implementado como um protocolo baseado na troca de mensagens XML, atende a diversos cenários de aplicação web, incluindo SSO e propagação de identidade;
• Utilizado para integração com aplicações terceiras como: Oracle WebLogic, Lotus Notes e SAP;
• Token no formato SAML 2.0;
• Mais informações em https://go.microsoft.com/fwlink/?LinkId=193996.

OAuth

• Desenvolvido pelo Internet Engineering Task Force (IETF);
• Utilizado para integração com aplicações Single Page Application (SPA), Universal Windows Plataform (UWP) e mobile WindowsPhone, IOS e Android;
• Token no formato JWT – JSON Web Token;
• Mais informações em https://oauth.net/ e https://msdn.microsoft.com/en-us/library/dn633593.aspx.

Neste artigo vou explicar passo a passo e dar dicas para você instalar da melhor maneira o ADFS 3.0 no seu ambiente.

O ADFS 3.0 exige pouca memória, disco e processador e em 100% dos casos que trabalhei com ADFS as máquinas eram virtuais. 2 processadores, 4 GB de memória e 100 GB de disco são suficientes. O Windows Internal Database ( nativo no Windows Server ) também é uma barata e eficiente escolha como banco de dados e será usada neste exemplo.

O ADFS é totalmente sensível e dependente de certificados digitais, você precisará de 3, mas só um deles o Service Communications precisará ser público, confiável e válido na Internet. Não use certificados emitidos por Certificates Authorities Internas como o ADCS nem certificados autoassinados para esta finalidade, além de não confiável e não estar na lista de Trust Root Certificate Authorities das máquinas a lista de certificados revogados raramente estão disponíveis para consulta.

NÃO ECONOMIZE AQUI, COMPRE UM CERTIFICADO ! No meu laboratório usarei o certificado *.labpfe.com que foi emitido pela DigiCert válido por um ano. Importe o certificado na máquina com o respectiva chave privada. (já dá para notar que certificados Wild Card são suportados)

Se o seu Active Directory está no nivel functional WS 2012 / R2 poderá utilizar uma conta de serviço chamada gMSA ( Group Managed Service Accounts ). Diferente de uma conta de usuário que é usada como serviço a gMSA você não define uma senha explicitamente, existe uma negociação direta entre o serviço e o serviço de KDC ( key distributed center ) do Domain Controller correspondente. O principal benefício deste modelo é não afetar o serviço quando a senha expira ou é alterada. Fica a dica. Mas procure saber se o seu serviço suporta este tipo de conta, o ADFS suporta e vamos ensiná-lo/a como configure-lo.

Para habilitar o gMSA no Active Directory você precise executar o seguinte commando:

C:\Add-KdsRootKey

Você poderá ter que esperar até 10 horas depois deste commando para que este serviço esteja disponível em todos os controladores de domínio da floresta, não tenha pressa, aguarde este período.

No meu laboratório eu executei o commando forçandoa hora como se fosse 10 horas atrás permitindo que eu continuasse o setup do ambiente. NÃO FAÇA ISSO EM PRODUÇÃO. Faça por fases, execute o commando em um dia e o resto do setup no outro.

Uma dica rápida para ver o nível functional da floresta é executar o commando Get-ADForest

Instale a função Active Directory Federation Services

Aguarde o fim da instalação e em seguida clique no ícone para iniciar o setup de configuração. Escolha a opção Create the first federation server in a federation server farm.

IMPORTANTE: Não existe mais a opção em instalar em Standalone ( um único servidor ) mesmo que você tenha uma única máquina a criação em Farm Mode é mandatória.

Você precisa ser um Domain Admin configurar o ADFS não basta ser um Local Admin. Por padrão ele sugere o mesmo usuário que está “logado” na máquina.

No campo SSL Certificate escolha seu certificado, informe o nome da sua farm, no meu caso adfs.labpfe.com e o nome amigável que aparecerá na tela de login do ADFS Forms Based Authentication.

Aqui chegou a hora de informar a conta de serviço gMSA, só escolha este modelo se atendeu os requisites explicados no início deste artigo ( nivel functional da floresta e o Root Key habilitado e aguardado no mínimo 10 horas). No campo informe um nome para a conta, observe que não é necessário digitar uma senha. Caso contrário escolha a opção “Use an existing domain user account or group MSA” e informe uma conta e senha previamente criada no AD ( este conta pode ser Domain Users somente ).

Deixe a opção Create a database on this server using Windows Internal Database. Se preferir utilize um servidor SQL server existente. Lembre-se ! Se o seu SQL Server não estiver em Cluster e ficar indisponível toda autenticação no ADFS será comprometida.

Opcionalmente instale tudo pelo PowerShell, este é um exemplo do commando. Simples mas não muito usual porque você precisará ter o ThumbPrint do certificado em mãos.

Aguarde o fim do setup, em seguida abra o DNS Manager e crie um registro A com o nome da sua farm que foi definida no setup apontando para o IP do servidor.

IMPORTANTE : NÃO USE TIPO DE REGISTRO CNAME ( APELIDO ) POIS NÃO É SUPORTADO. SE EXISTIR UM BALANCEADOR DE CARGA DE REDE NA FRENTE APONTE PARA O ENDEREÇO IP VIP

Faça um teste simples de ping e veja se o novo da farm esta respondendo com sucesso.

DICA : Quando acessar o ADFS pela primeira vez inevitavelmente terá a segunte experiência : um pop up será aberto para autenticação e o single sign on não acontecerá. Isso acontece não por um problema no AFDS mas sim por uma característica do Internet Explorer que pelo fato de estar acessando um serviço com nome público neste caso adfs.labpfe.com o navegador acredita que não esta na intranet e sim na Internet. Para corrigir isso faça o seguinte :  Abra o internet explorer na máquina do usuário ou na sua, escolha opções de Internet, guia security, escolha local intranet e clique no botão Sites, e depois em Advanced. Adicine aqui o endereço do seu ADFS iniciando em https:

É claro que aqui estará pensando em como fazer isso em massa/lote para vários computadores da rede, afinal todos eles terão que ter esta configuração. Recomendo este artigo que explica como fazer isso.

https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html

Uma vez configurado, acesse o endereço https://fqdnadfsname/adfs/ls/idpinitiatedsignon.aspx. No meu caso https://adfs.labpfe.com/adfs/ls/idpinitiatedsignon.aspx. Clique em Sign In. ( todo ADFS bem configurado precisa expor este endpoint na Internet).

Ao clicar em Sign In você deve ser autenticado diretamente ( isso é logon único, sso, foi aproveitado o token Kerberos da sua máquina). Se abrir um Pop up você não configurar o local intranet sites no item acima corretamente.

Dica agora sobre o certificado. Por padrão o certificado gerado para Token Signing e Decrypting é auto-assinado e válido por um ano. Um ano é muito pouco tempo em especial para o Token Signing.

Vamos definir um periodo maior de tempo para estes certificados, vamos alterar para 5 anos ou 1825 dias.

Podemos ver o resultado da alteração executando o commando Get-ADFSProperties

Execute os commandos abaixo para forçar de maneira urgente a alteração dos certificados Token Signing e Decrypting

Ao abrir a console do ADFS/Certificates, a data de expiração do certificado foi alterado para 2021 e não mais 2017 como originalmente ( 5 anos )

Outra dica bacana é alterar o logo de ilustração padrão do ADFS, aquela imagem grande Azul a esquerda do formulário.

Copie uma imagem com resolução 1420 x 1080 pixesls da sua preferência e execute o commando acima referenciando a imagem. Veja o resultado como ficou legal. Se você quer saber todos os commandos para alterar outras áreas do formulário leia este artigo: https://technet.microsoft.com/en-us/library/dn280950.aspx

DICA:  O ADFS Proxy no ADFS 3.0 não existe mais. O serviço que expôe o ADFS na Internet agora se chama Web Appliction Proxy (WAP) e é uma subfeature do Remote Access e não mais do ADFS.

Não publique diretamente o ADFS na rede local diretamente na Internet. O WAP é alvo para um artigo dedicado somente para ele, pois além de atuar como ADFS Proxy ele tem outra função de publicação muito interessante que explicarei em um novo artigo. Até lá.

• 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.

• 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.

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.