O subsistema de disco é o gargalo mais comum. O 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 e acesso mais comum em implementações do eDirectory.
Algumas soluções para cargas de trabalho aleatórias:
Aumente a memória RAM. Ela permite armazenar frequentemente em cache os dados do usuário ou 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 FLAIM RFL. Este 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 onde 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 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 JFS de alto desempenho, capaz de trabalhar com grandes arquivos e oferecendo transferências de dados suaves. O eDirectory 8.8 SP8 é suportado em plataformas SLES 11 32 e 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. Este é 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 do bloco do banco de dados for maior do que o tamanho do 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 do bloco do FLAIM igual ao do sistema de arquivos.
O tamanho do bloco pode ser controlado apenas durante a criação do DIB. Acrescente uma linha "blocksize=8192" ao _ndsdb.ini para criar um DIB com tamanho de bloco 8k.
Escolher o tamanho correto de bloco depende do tamanho médio do registro do FLAIM das suas implementações. É necessário realizar testes empíricos no conjunto correto de dados de teste para determinar qual tamanho de blocos é o melhor para sua implantação.