O subsistema de disco é o gargalo mais comum. A E/S leva relativamente muito tempo com filas mais longas, resultando em alta utilização de disco e ciclos de CPU inativos. Use a ferramenta iostat durante os picos esperados para determinar os indicadores de tempo de resposta média.
As operações de leitura, gravação e atualização de disco podem ser sequenciais ou aleatórias. Leituras e atualizações aleatórias são o padrão de acesso mais comum em implantações do eDirectory.
Algumas soluções para cargas de trabalho aleatórias:
Aumente a memória RAM. Isso permite armazenar em cache os dados frequentemente usados ou os dados de leitura antecipada na camada do sistema de arquivos. Ela também permite armazenar em cache o DIB dentro do subsistema do FLAIM.
Use volumes dedicados para o DIB. O desempenho do sistema de arquivos melhora para volumes criados mais próximos ao fuso. Use volumes dedicados para o RFL e outros registros.
À medida que o disco desenvolve latência crescente com o passar do tempo devido à fragmentação, ele deverá ser desfragmentado.
Adicione unidades de disco separadas para RFL do FLAIM. Esse tipo de registro pode ser realizado em discos de alta velocidade.
Use um ambiente RAID 10(1+0) com mais unidades de disco.
Os arquivos criados pelo eDirectory podem crescer até 4 GB. Os sistemas de arquivos otimizados para lidar com grandes arquivos trabalham bem com o eDirectory.
Para Solaris™, o sistema de arquivos Veritas* VxFS é um sistema de arquivos baseado em extensão no qual os metadados do sistema de arquivos são otimizados para grandes arquivos. O sistema de arquivos UFS é indiretamente baseado em blocos, no qual os metadados do sistema de arquivos são armazenados em um grande número de blocos. Ele pode até mesmo ser dividido para grandes arquivos, o que torna o UFS mais lento para grandes arquivos.
Para Linux™, o sistema de arquivos Reiser é um sistema JFS rápido que trabalha melhor que o sistema de arquivos ext3 em grandes conjuntos de DIB. Contudo, o modo de registro em diário de gravação inversa do ext3 é compatível com o desempenho do sistema de arquivos Reiser, embora o modo padrão ofereça maior consistência de dados. O XFS é um sistema JFS de alto desempenho, capaz de trabalhar com grandes arquivos e oferecer transferências de dados suaves. O eDirectory 9.0 é suportado no SLES 11 32 e com as plataformas de 64 bits que possuem o sistema de arquivos XFS.
O FLAIM suporta um tamanho de bloco de 4 KB a 8 KB. O padrão é 4 KB. Esse é o mesmo tamanho de bloco padrão do Linux (tune2fs -l device). Contudo, no Solaris, o sistema de arquivos UFS é criado com um tamanho de bloco padrão de 8 KB (df -g mountpoint). Se o tamanho de bloco do FLAIM for menor do que o do sistema de arquivos, poderá ocorrer gravação parcial de bloco. Se o tamanho de bloco do banco de dados for maior do que o tamanho de bloco do sistema de arquivos, leituras e gravações individuais de blocos serão divididas em uma série de operações de E/S físicas separadas. Portanto, é necessário sempre manter o tamanho de bloco do FLAIM igual ao do sistema de arquivos.
O tamanho de bloco pode ser controlado apenas durante a criação do DIB. Acrescente uma linha "blocksize=8192" ao _ndsdb.ini para criar o DIB com tamanho de bloco igual a 8k.
Escolher o tamanho correto de bloco depende do tamanho médio do registro do FLAIM das suas implantações. É necessário realizar testes empíricos no conjunto correto de dados de teste para determinar qual tamanho de bloco é o melhor para sua implantação.