Lazy writer é o processo responsável por escrever os dados em disco de forma assíncrona, além de desempenhar um papel importante no gerenciamento de memória.

• Escrita assíncrona de dados?

Sim! Os comandos UPDATE/INSERT/DELETE são gravados no Transaction Log de forma síncrona, mas realizam as modificações dos dados em memória. Nesse momento, o comando finaliza e o controle retorna ao usuário. Em background, o processo de lazy writer transfere as informações para os arquivos de Dados.

• Qual o papel do Lazy writer no gerenciamento de memória?

Durante a execução do Lazy writer, o tamanho do Buffer Pool (também conhecido como Data Cache) é recalculado e libera-se memória se necessário.

Apenas como curiosidade, o Lazy writer é um processo de sistema e pode ser observado através da query:

   SELECT*FROMsys.dm_exec_requests
   WHEREcommand ='LAZY WRITER'

Ao rodar o SELECT anterior na minha máquina, observamos que o lazy writer roda como SessionID 4 em background.

Em servidores de arquitetura NUMA, uma instância SQL Server possui um Lazy writer para cada Memory Node.

No último post sobre "Cache de Disco”, comentei sobre a importância do Write-Cache.

Entretanto, existe um risco em deixá-lo habilitado.

O que acontece com a memória cache se houver falta de energia?

As informações gravadas em cache são voláteis e podem ser perdidas se acabar a energia elétrica. Isso pode causar perda de dados e estrago nas estruturas internas das tabelas e do banco de dados.

Portanto, a resposta é sempre evitar a falta de energia elétrica (caso esteja com write-cache habilitado).

• Uso de no-breaks nos servidores com disco local: Garante que o servidor e seus dispositivos possam efetuar a gravação de dados antes de acabar a energia elétrica.
  
• Controladoras com bateria: Existem controladoras que possuem bateria para manter os dados em cache mesmo quando desligada. Quando o servidor é ligado novamente, a controladora descarrega o conteúdo do cache para os discos. Mas não esqueça de conferir o tempo de vida das baterias e trocá-las conforme a recomendação do fabricante.
  
• Storage: Normalmente há fontes de alimentação redundante e que devem ser ligadas em diferentes redes elétricas. Em geral, os geradores de energia dos Data Centers garantem que não haverá falta de energia.

No próximo post, farei os comentários sobre cache de leitura (de novo!) e as limitações do cache de escrita.

Podemos encontrar o cache em um Storage, nas controladoras e nos próprios discos. Qual a importância do cache?

Cache = Performance.

Existe duas formas de utilizar o cache.

Cache de Leitura

Esse cache agiliza operações que façam a leitura do mesmo setor diversas vezes seguidas.

Pergunta: Qual a probabilidade do SQL Server realizar diversas leituras do mesmo dado?

Resposta: Quase zero.

Será que me expliquei bem? Como o SQL Server mantém um cache de dados, dificilmente ele necessita repetir a leitura em disco. Atualmente, encontramos servidores com 32GB de memória - quase tudo para manter os bancos/tabelas em memória.

Cache de Escrita

Ao contrário do cache de leitura, esse é um cache fundamental para obter alta performance.

Write-Cache = MUITA PERFORMANCE

Pense em toda parte mecânica do disco envolvida durante o processo de escrita: demora 2ms em um disco rápido de 15k RPM. Uma única operação de escrita pode ser completada em microssegundos (ou nanossegundos?) em cache. Isso é muita performance!

Conclusão: Configure o máximo de cache para escrita.

Nos próximos posts, gostaria de adicionar algumas considerações sobre cache. Existem limitações e riscos que devem ficar claros.

Nas visitas a clientes, é muito comum ouvir perguntas sobre como otimizar a performance dos discos.

A primeira recomendação que fazemos é para manter os arquivos de Dados e Log em discos separados. Por exemplo:

• Disco L: arquivos LDF (Log)
• Disco R: arquivos MDF/NDF (Dados)
• Disco S: arquivos MDF/NDF (Dados)
• Disco T: arquivos MDF/NDF (Dados)

Em um disco de 15k RPM, o tempo médio de escrita é de 5,5ms. Se colocarmos o arquivo de Log em um disco dedicado, é possível obter tempos de 2ms por escrita!

Vamos aos cenários:
 

Cenário 1: Leitura de Arquivos de Dados

Consideramos as operações de leitura de dados, que cada hora é lida uma página diferente e em posição distinta no disco. Para cada requisição de leitura, será necessário posicionar no track e, em seguida, posicionar no setor.  

O tempo médio para a operação completar será de 5,2ms.

Cenário 2: Escrita no Transaction Log

As escritas no arquivo de transaction log são sequenciais. Isso significa que, após o primeiro posicionamento do cabeçote no track, as operações seguintes precisam apenas realizar o posicionamento de setor.
 

Por isso, dizemos que as escritas no transaction log tiram vantagem do fato de serem sequenciais e o tempo médio da operação é de apenas 2ms.

Cenário 3: Arquivos de Dados e Log no mesmo disco físico

Quando colocamos os arquivos de Data (MDF/NDF) e Log (LDF) no mesmo disco físico, observamos que o tempo de escrita em log aumenta para 5,5ms. Isso ocorre porque as operações de leitura/escritas são intercaladas e o cabeçote deve sempre ser reposicionado, deixando de tirar proveito do fato das escritas em log serem sequenciais.

Conclusão:

Nunca misture os arquivos de Dados e Log, porque há impacto direto no tempo de escrita do Transaction Log. Como observamos, toda operação de escrita terá a necessidade de reposicionar o cabeçote no track correto, aumentando o tempo de resposta.

Ao colocar o arquivo de Transaction Log em um disco dedicado, teremos uma performance otimizada para as escritas sequenciais.

Durante o TechEd 2009, ouvi um comentário do Fernando Garcia (gente fina!) sobre o diagnóstico de problemas de falta de memória usando a DMV: dm_os_ring_buffer e filtrando por registros do tipo RING_BUFFER_RESOURCE_MONITOR. Afinal, que tipo de informação fica armazenada?

SELECT * FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR'
ORDER BY timestamp DESC

A primeira parte do resultado descreve qual o tipo de notificação.

<Record id="0" type="RING_BUFFER_RESOURCE_MONITOR" time="146278552">
  <ResourceMonitor>
    <Notification>RESOURCE_MEMPHYSICAL_HIGH</Notification>
    <IndicatorsProcess>0</IndicatorsProcess>
    <IndicatorsSystem>1</IndicatorsSystem>
    <NodeId>0</NodeId>
    <Effect type="APPLY_LOWPM" state="EFFECT_OFF" reversed="0">0</Effect>
    <Effect type="APPLY_HIGHPM" state="EFFECT_ON" reversed="0">0</Effect>
    <Effect type="REVERT_HIGHPM" state="EFFECT_OFF" reversed="0">0</Effect>
  </ResourceMonitor>

Os eventos possíveis são:

• RESOURCE_MEMPHYSICAL_HIGH
• RESOURCE_MEMPHYSICAL_HIGH
• RESOURCE_MEM_STEADY
• RESOURCE_MEMVIRTUAL_LOW

Esses eventos podem ser internos/externos à instância do SQL Server, conforme a indicação dos campos:

• IndicatorsProcess
• IndicatorsSystem

Resource Monitor fará o broadcast dessa notificação para todos os componentes de memória.

A segunda parte detalha cada um dos Memory Nodes, apresentando a distribuição de memória entre os “Allocators”.

  <MemoryNode id="0">
    <ReservedMemory>6282232</ReservedMemory>
    <CommittedMemory>38712</CommittedMemory>
    <SharedMemory>0</SharedMemory>
    <AWEMemory>8192</AWEMemory>
    <SinglePagesMemory>3208</SinglePagesMemory>
    <MultiplePagesMemory>21896</MultiplePagesMemory>
  </MemoryNode>

A terceira parte apresenta informações importantes sobre o status do Sistema Operacional e do processo do SQL Server.

  <MemoryRecord>
    <MemoryUtilization>100</MemoryUtilization>
    <TotalPhysicalMemory>6222536</TotalPhysicalMemory>
    <AvailablePhysicalMemory>3044516</AvailablePhysicalMemory>
    <TotalPageFile>12665292</TotalPageFile>
    <AvailablePageFile>9388376</AvailablePageFile>
    <TotalVirtualAddressSpace>8589934464</TotalVirtualAddressSpace>
    <AvailableVirtualAddressSpace>8583481552</AvailableVirtualAddressSpace>
    <AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace>
  </MemoryRecord>
</Record>

Descrição dos campos:

• MemoryUtilization: Utilização de memória RAM pelo SQL Server
• TotalPhysicalMemory: Quantidade total de memória RAM
• AvailablePhysicalMemory: Memória RAM disponível
• TotalPageFile: Quantidade total de committed memory
• AvailablePageFile: Quantidade de committed memory disponível
• TotalVirtualAddressSpace: Espaço virtual do processo
• AvailableVirtualAddressSpace: Espaço virtual disponível

A próxima pergunta é como analisar? Não responderei isso nesse post.. mas pretendo em breve descrever como funciona o Resource Monitor e o gerenciamento de memória do SQL Server.

No post anterior, comentei sobre a parte mecânica do disco. Agora vamos ler a especificação de um disco e entender de que forma podemos otimizar sua performance ao máximo.

Escolhi um disco Savvio 15K RPM 146GB.
http://www.seagate.com/www/en-us/products/servers/savvio/savvio_15k.2

A especificação do disco é semelhante ao quadro abaixo:

A interface corresponde a forma de comunicação entre o disco e a controladora, sendo as mais comuns: ATA, SATA, SCSI, SAS e FC. No exemplo do disco Savvio, a interface usada é SAS com 3-GBit, que permite a transferência de 300 MB/s.

Em seguida, observamos a velocidade de rotação do disco (spindle speed). Em servidores, as velocidades mais comuns são 7200, 10000 e 15000 RPM - enquanto meu notebook roda a modestos 5400 RPM. A velocidade do motor influencia diretamente na performance do disco, portanto, vamos ficar de olho nele!

Os tempos de posicionamento:

• Average Latency: Tempo necessário para posicionar o cabeçote no setor correspondente. Esse tempo depende exclusivamente da velocidade de rotação do motor (spindle)
• Average Read/Write Seek Time: Tempo médio necessário para o atuador posicionar o cabeçote no track correspondente.
• Track-to-track Time: Tempo necessário para o atuador movimentar-se para o track adjacente.

Seguindo os valores especificados para o disco, é necessário aproximadamente 3ms para posicionar o cabeçote no track e mais 2ms para posicionar no setor correto. Caso seja necessário deslizar o cabeçote para o track seguinte, então serão gastos mais 0,2ms. Essas operações de milissegundos são uma eternidade para o computador, por isso, o tempo de acesso corresponde normalmente ao gargalo.

Uma vez posicionado no setor correto, a leitura inicia-se com uma taxa de transferência entre 122-160 MB/s. Essa informação pode ser obtida através do Sustained Transfer Rate ou Internal Transfer Rate.

Todos os discos apresentam um cache interno denominado Buffer. Ao contrário dos caches de memória L1/L2, ter um buffer maior não garante melhor performance. Esse disco tem 16MB - se tivesse 32MB, a performance seria praticamente igual.

Por fim, temos a característica geométrica do disco: 2 platters, 4 heads e setores de 512 bytes.

Comparando alguns discos: 

• Disco 1: Constellation 160GB
• Disco 2: Savvio 10k RPM 73GB
• Disco 3: Savvio 15k RPM 73GB
• Disco 4: Savvio 15k RPM 146GB

Esse resultado mostra que a capacidade do disco não tem relação com performance. Devemos sempre olhar a velocidade de rotação do disco – 15000 RPM é o disco mais rápido. Outro ponto interessante é que a interface não influenciou na escolha do disco. Todas as interfaces permitem a transferência de 300 MB/s, muito superior ao Transfer Rate dos discos.

Como tirar melhor proveito da performance do disco?

Lembro-me de um curso que tive sobre Storage, no qual o instrutor começava perguntando se alguém sabia o que era um disk drive. Ao mesmo tempo que a resposta parecia óbvia ("Lógico que sim!!!"), todos na classe sabiam que havia algo mais na pergunta. Ele deixou claro que queria começar do zero e logo mostrou algumas ilustrações de disco.

Primeiro, foram descritos os principais componentes de um disk drive:

• Platter - São os discos magnéticos que armazenam os dados.
• Head (Cabeçote) - Dispositivo responsável por realizar a leitura/gravação em disco.
• Arm/Actuator (Atuador) - Corresponde a parte móvel que permite a movimentação da cabeça para posicionamento.
• Spindle (Motor) - Esse é o motor que gira em velocidade constante.

Em cada platter, podemos imaginar vários círculos concêntricos com tamanhos variados. Cada círculo corresponde a um track e o conjunto de tracks (em um formato tridimensional), a um cilindro.

Finalmente, cada track é dividido em vários setores - na grande maioria dos discos, cada setor possui 512 bytes.

Vou tentar descrever o que acontece quando uma operação de leitura é realizada:

1. A informação a ser lida é traduzida em uma coordenada no disco, seguindo o formato CHS (Cylinder/Head/Sector)
2. O atuador posiciona o cabeçote no cilindro/track correspondente ao dado
3. O motor gira até a posição correspondente do setor dentro do track
4. A leitura é realizada através do cabeçote correspondente ao platter

Prestem bastante atenção aos pontos 2 e 3.

Quanto tempo que o atuador precisa para posicionar o cabeçote no cilindro correspondente?

Resposta: Seek Time.

Quanto tempo que o motor necessita para posicionar o cabeçote no setor correspondente?

Resposta: Rotation Latency Time.

Essas informações estão presentes na especificação do disco.

EXEMPLO:

Disco Seagate Savvio

http://www.seagate.com/www/en-us/products/servers/savvio/savvio_15k.2/

PERFORMANCE
Spindle Speed	15,000 rpm
Average latency	2.0 msec
Random read seek time	3.2 msec
Random write seek time	3.5 msec

No próximo post, continuaremos olhando esses números.

Olá Pessoal!

Meu nome é Fabricio Catae e sou Premier Field Engineer com foco em Database.

Minha carreira começou em um programa de estágio na Microsoft Consulting Services (MCS) e após um ano me tornei um Field Engineer no Suporte Premier. Nesse mesmo período tive a oportunidade de trabalhar com os Rapid Response Engineer (RRE) e Solution Integration Engineer (SIE), que formavam a elite do suporte em conjunto com o time de Critical Problem Resolution (CPR). Essa foi uma experiência fantástica, pois aprendi os bits/bytes dos nossos produtos Microsoft. Em 2007, consegui me certificar como "SQL Ranger" (atualmente corresponde ao Microsoft Certified Master). Nos últimos tempos, tenho me aprofundado mais na parte de Storage e BI/DW.

A idéia de ter um blog surgiu esses dias enquanto preparava a minha apresentação no TechEd Brasil junto com a Aline Maia. Vamos apresentar uma mistura de Sharepoint com SQL. E ela é fera no assunto! Para não passar vergonha, decidi estudar um pouco sobre Sharepoint, começando pelo blog dela e de pouco em pouco fui vendo um monte de coisa legal e - BING! - deu vontade de ter um blog também!!!

Espero que gostem dos assuntos postados.

Abraços
Fabricio