Lentidão no Exchange Server 2003 e NTBACKUP

por Alessandro Goncalves

Por mais que estejamos já na versão Exchange Server 2010 , ainda existem muitos clientes utilizando o Exchange Server 2003. Não faz muito tempo trabalhei em um incidente interessante , pois apenas aplicando pequenas mudanças conseguimos aumentar consideravemente a performance do NTBACKUP contra o Exchange Server 2003 ao realizar gravação no disco.

Primeiramente , esse é o cenário que estarei utilizando , Windows Server 2003 , Exchange Server 2003 e os jobs de backup com NTBACKUP e toda a gravação em disco. Este é um cenário muito comum , onde escolhemos um disco local como destino do backup e uma outra operação transfere o arquivo para um dispositivo remoto. Durante a implementação deste sistema , temos um desempenho bom , mas com o crescimento das bases de dados , a performance começa a diminuir drasticamente chegando ao ponto de ultrapassar a janela de backup. Isso se deve ao fato de cada vez os arquivos de base de dados Exchange .EDB começam a ficar com um tamanho considerável e quanto maior esse tamanho , pior será a performance de backup. Um exemplo desta queda de performance é quando copiamos arquivos muito grandes através da rede e vemos a performance cair.

No incidente de suporte no qual trabalhei , o cliente estava realizando um Backup Full de todos os Storage Groups do Exchange diariamente , e o tempo para completar tal operação estava superior a 18 horas !!! O objetivo do incidente era verificar se existia alguma forma de “melhorar” a performance da operação de backup sem ter que modificar a estrutura e/ou o tipo de backup (diferencial / incremental). O destino do backup era o disco local.

Estes resultados são apenas de um dos jobs de backup ocorrendo , mas vemos que o tempo de backup está durando cerca de 13 horas e que a performance está degradando com o passar do tempo , pois o primeiro Storage Group demorou 2 horas e 25 minutos para cerca de 88 GB de dados e ultimo Storage Group demorou cerca de 4 horas para cerca de 56GB de dados. Ou seja, a performance além de estar defasada está decaindo com o decorrer do tempo.

Para o NTBACKUP existem algumas chaves de registro que podemos adicionar para melhorar o throughput de dados da engine do NTBACKUP. Essas chaves serão inseridas na conta de serviço que está sendo utilizada para realizar o backup , e que obviamente tenha as permissões necessárias sobre o Exchange Server.

Abra o editor de registro , utilizando a conta de serviço de backup e edite as seguintes chaves para esses valores:

HKEY_CURRENT_USER\Software\Microsoft\Ntbackup\Backup Engine
Logical Disk Buffer Size – 64
Max Buffer Size – 1024
Max Num Tape Buffers -16

Essas mudanças no registro aumentam o throughput da engine de backup , porém devem ser implementadas com a última versão disponível do NTBACKUP e o job de backup estar sendo executado com o parâmetro /FU (Unbuffered I/O) , observem a explicação deste parâmetro no artigo KB839272 - System performance is negatively affected when Ntbackup.exe writes to a destination .bkf file, onde o buffer do Cache Manager e Memory Management acabam por se tornar um bottleneck na performance e impedindo um maior throughput no procedimento de backup.

Após as mudanças no registro e principalmente no script de backup onde foi adicionado /FU , temos os seguintes valores para os mesmos Storage Groups , utilizando as mesmas opções na operação.

A diferença no número de arquivos se deve a quantidade de logs de transação criados a cada dia e a quantidade de bytes , também ao número de logs mais o crescimento dos arquivos EDB e STM.

Podemos ver claramente a diferença de tempo para antes e depois das mudanças do backup. Esta melhora está diretamente ligada ao parâmetro /FU no job de backup , o qual força com que o NTBACKUP realize Unbuffered I/O , o que faz entre outras coisas a não utilizar o Cache Manager do sistema operacional.

Basicamente o Cache Manager é um conjunto de funções de kernel e threads de sistema que em conjunto com o Memory Manager fornecem cache de dados para todos os drivers de File System ( tanto local e remota). Nisto se inclui o processo de cache de arquivos (File Caching) .

Uma pequena definição de File Caching , é que o Windows faz o cache de dados de operações de leitura e escrita nos discos , isto implica que operações de leitura obtém dados de arquivo de uma area de memória conhecida como “system file cache” , ao invés de diretamente do disco. O mesmo acontece com operações de escrita de arquivos , onde dados são colocados no “system file cache” , também conhecido como write-back cache.

O processo de cache acontece sob o controle do Cache Manager , o qua está sempre ativo. Dados são transferidos do system file cache em intervalos pre-determinados pelo sistema operacional , e nesse ponto a memória utilizada é liberada – flushing the cache . Esse processo de prorrogar a escrita dos dados diretamente ao sistema de discos e armazenando o mesmo em cache é conhecida como “lazy writing” . O cálculo de quando o processo de flush de um determinado bloco do system cache é feito depende do tempo que o mesmo está armazenado e da quantidade de tempo desde que foi feito algum tipo de acesso de leitura a esse bloco de memória. Isso nos assegura que dados frequentemente acessados permanecerão no system file cache o máximo possível.

A figura acima representa uma operação de leitura , onde um bloco de 256KB é requisitado e transferido para uma area “controlada” pelo system cache (System Address Space). O processo que requisitou os dados copia os dados do System cache para um espaço de memória privado . Quando a manipulação daquelo bloco de dados é finalizado pelo processo , o mesmo escreve no mesmo espaço original no System Cache. Após a avaliação do Cache Manager de que os dados não serão mais acessados por um período de tempo , é feito o lazy write das modificações armazenadas no System Cache para o disco , assim liberando espaço de memória.

Com esse conceito podemos verificar que ao utilizarmos blocos de dados extremamente grandes em operações de leitura e gravação , aumentam a nossa possibilidade de preencher completamente o espaço reservado ao System Cache , pois estamos aguardando que o mesmo avalie que os blocos de memória possam ser liberados. Assim criando um bottleneck , pois a operação de writefile estará esperando espaço no System Cache para completar I/O’s e prosseguir para o próximo bloco de dados , assim diminuindo a performance geral do sistema em operações de leitura e gravação de arquivos grandes , em nosso caso a operação de backup dos arquivos .EDB e .STM para o disco local.

Ao adotarmos a opção /FU ,no NTBACKUP, indicamos que essa operação sera do tipo Non-Buffered , onde fazemos um bypass do Cache Manager para essa operação e escrevemos diretamente ao hardware . Como podemos ver isso trouxe um resultado bem expressivo na operação de backup.

Ao copier arquivos extremamente grandes (local ou remotamente) experimentamos esse mesmo tipo de limitação em relação ao System Cache. Para controlarmos esse comportamento de utilizar o system cache ou não , devemos ver se há existem opções na operação de cópia para “desabilitarmos” esse comportamento apenas para aquela operação , por exemplo copiar um arquivo de 1GB para uma pasta compartilhada . Existem na função CreateFile , o parâmetro dwFlagsandAttributes que controla / afeta o comportamento do system cache em relação aos dados associados com o handle.

Mas como podemos utilizar esse mecanismo de cópia Non-Buffered em nosso dia a dia ?

Existe um switch do utilitário ESEUTIL que faz cópia de dados do tipo Non-Buffered por padrão. Ao utilizarmos o ESEUTIL /Y , ou o antido ESEFILE , estamos fazendo uma cópia de arquivos sem a utilização do Cache Manager .É bom lembrar que podemos utilizar o ESEUTIL mesmo não tendo Exchange Server instaldo , apenas necessitamos seguir esse artigo : 244525 How to run Eseutil on a computer without Exchange Server

Outra opção para usuários de Windows 7 , é o XCOPY com a opção /J , que ao observarmos o help :

/J – Copies using unbuffered I/O. Recommended for very large files.

Espero que essa informação tenha esclarecido dúvidas em relação ao Cache Manager e como conhecer um pouco da arquitetura do sistema pode ajudar em compreender certos comportamentos do sistema operacional.

Obrigado,