Desempenho dos sistemas de arquivos no Maildir

O Maildir é um formato para armazenamento de mensagens de e-mail implementado por Daniel J. Bernstein – autor do Qmail – que buscava uma alternativa ao antigo e bastante criticado formato Mbox. Com o passar do tempo, o Maildir transformou-se em uma opção para diversos servidores SMTP além do Qmail, incluindo os renomados Sendmail, Postfix e Exim.

Hoje, tendo em vista a crescente utilização desse formato, paira uma indefinição: Qual é o sistema de arquivos que oferece melhor desempenho?

Para tentar obter respostas, foram realizados testes de performance específicos para o formato Maildir no sistema operacional Linux, usando a distribuição CentOS 5, e levando em consideração os sistemas de arquivos ditos mais populares: ReiserFS, XFS, JFS e EXT3.

Maildir vs Mbox

O principal diferencial do Maildir em relação ao Mbox é a sua compatibilidade com sistemas de arquivos de rede, como, por exemplo, o NFS e o GFS. A compatibilidade pode ser explicada pelo fato desse formato utilizar um arquivo para cada mensagem de e-mail, enquanto que o Mbox armazena todas as mensagens em um único arquivo. Essa característica do Maildir evita a possibilidade de ocorrer um mecanismo conhecido como file locking, em que o arquivo é travado para gravação enquanto algum outro processo estiver gravando nele.

Não é necessário muito esforço para deduzir que essa diferença entre o Maildir e o Mbox também afeta grosseiramente o método de acesso ao sistema de arquivos. No Mbox, o acesso a um único arquivo exige desempenho para escrita e leitura seqüencial. No Maildir, os acessos são aleatórios entre os vários arquivos criados para cada mensagem. Assim, um sistema de arquivos que tem um bom desempenho para ler mensagens no formato Mbox, pode sofrer ao tentar ler essas mesmas mensagens no formato Maildir.

O fsbench

Para a realização dos testes de performance foi usado o fsbench, um conjunto de scripts Perl que simula os processos de entrega e leitura de mensagens em um diretório no formato Maildir. De acordo com o autor do fsbench, resumidamente os scripts funcionam obedecendo os seguintes passos:

1. O sistema de arquivos é formatado e montado.
2. Uma estrutura de diretórios é criada, com o equivalente a 100.000 caixas postais no formato Maildir.
3. É executado simultaneamente um processo de escrita (entrega) e outro de leitura de mensagens. O script aguarda a finalização de cada processo e então roda o comando sync, para sincronizar os dados do buffer com o disco.
4. Os passos anteriores são repetidos com 2, 4, 8 e 16 processos de escrita executados simultaneamente.

Estes mesmos testes já foram realizados pelo próprio autor do fsbench, porém, em Maio de 2004, usando o Gentoo Linux com kernel 2.6.5. Agora o objetivo é obter novos dados com uma distribuição mais recente, visto que os sistemas de arquivos envolvidos nos testes, além do kernel, sofreram importantes alterações durante esse período.

Journaling

Os sistemas de arquivos considerados modernos – alvos dos testes de performance – possuem um recurso a ser estudado quando o assunto é desempenho: o Journaling.

O conceito de journaling pode ser extremamente resumido como sendo o registro em um arquivo de log, chamado de journal, de todas as alterações realizadas no sistema de arquivos. A idéia por trás dele é permitir uma recuperação rápida e confiável em caso de um desligamento incorreto, pois a checagem de integridade se limitará aos registros do journal, e não a todo o sistema de arquivos.

Nos sistemas de arquivos ReiserFS, XFS e JFS, o journaling registra apenas as modificações dos metadados, que são as informações a respeito dos próprios arquivos, como, por exemplo, o nome do arquivo, tamanho, permissões de acesso e horários de modificação, criação e acesso. Isso é o suficiente para garantir a integridade do sistema de arquivos, mas não dos dados em si, que podem ser perdidos ou truncados após uma falha.

Apesar do risco, esse método de journaling oferece um excelente desempenho por justamente não se preocupar com o conteúdo dos arquivos modificados. Entretanto, é válido considerar que os sistemas têm necessidades distintas e, portanto, ter opções é primordial.

E pensando em oferecer essas opções e preencher a lacuna entre a segurança dos dados e o desempenho, especificamente o EXT3 possui três diferentes métodos de journaling:

• Journal, onde tanto os metadados quanto o conteúdo dos arquivos são escritos no journal antes de serem de fato escritos no sistema de arquivos. Isso aumenta a confiabilidade do sistema com uma perda de desempenho, devido a necessidade de todos os dados serem escritos duas vezes.
• Writeback, onde apenas os metadados são escritos no journal. Esse método é mais rápido, porém os dados do journal e do sistema de arquivos são escritos fora de ordem. Dessa maneira, arquivos modificados durante uma falha do sistema podem ter adicionados a eles trechos de lixo após a próxima montagem.
• Ordered, é como o writeback, mas força que a escrita do conteúdo dos arquivos seja feita após o registro de seus metadados no journal. Esse método é considerado um meio-termo aceitável entre confiabilidade e performance, sendo, portanto, o padrão.

Para fins de comparação, os testes de performance examinaram os três métodos de journaling do EXT3.

Detalhes do sistema

O sistema usado para os testes tem as seguintes características:

• CPU: 2 Xeon X3210 Quad Core – 2.13GHz
• RAM: 4 GB DDR2 667
• Controladora RAID: 3ware 9650SE-8LP
• Nível do RAID: RAID 10 com 8 Discos SATA2 7200 RPM
• Sistema Operacional: CentOS 5 com kernel 2.6.18-8.1.15.

Em se tratando dos sistemas de arquivos, visando aumentar o desempenho para o formato Maildir, eles foram formatados e montados usando opções específicas, conforme a listagem a seguir:

EXT3 (ordered)

• Comando de formatação: mke2fs -j -J size=400 -i 8192 -O dir_index
• Opções de montagem: noatime,data=ordered

EXT3 (writeback)

• Comando de formatação: mke2fs -j -J size=400 -i 8192 -O dir_index
• Opções de montagem: noatime,data=writeback

EXT3 (journal)

• Comando de formatação: mke2fs -j -J size=400 -i 8192 -O dir_index
• Opções de montagem: noatime,data=journal

XFS

• Comando de formatação: mkfs.xfs -f -l size=32768b,version=2
• Opções de montagem: noatime,logbufs=8,logbsize=131072

ReiserFS 3.6

• Comando de formatação: mkreiserfs –journal-size 32749 –format 3.6
• Opções de montagem: noatime,notail

JFS

• Comando de formatação: jfs_mkfs
• Opções de montagem: noatime

Entre todas as opções listadas, vale comentários para o noatime (no access time), que evita a atualização do horário de acesso dos arquivos e, portanto, aumenta o desempenho em um cenário onde ocorrem vários acessos simultâneos. A opção dir_index, exclusiva do EXT3, cria um índice usando o algoritmo b-tree para acelerar a localização dos arquivos. Os demais sistemas já empregam o algoritmo b-tree para armazenar informações sobre seus arquivos.

Metodologia

Os testes do fsbench foram executados três vezes para cada sistema de arquivos. Nas primeiras duas execuções os scripts foram configurados para simularem as entregas e leituras de mensagens durante 2 minutos. Na última, o tempo foi aumentado para 10 minutos. As médias entre os valores obtidos nas três execuções foram utilizadas para montagem dos gráficos.

Por se tratar de um teste que visa determinar exclusivamente o desempenho dos sistemas de arquivos, o uso de CPU de cada um deles não foi considerado. Apesar dessa informação ser útil para análise em determinadas configurações, nos servidores de e-mail de larga escala a porcentagem de uso de CPU do sistema de arquivos é um valor neglicenciável.

Não foi utilizado dispositivo separado para o journal dos sistemas de arquivos testados. Essa é uma configuração recomendada para aumentar o desempenho de escrita, desde que o dispositivo do journal seja mais rápido que o dispositivo do sistema de arquivos principal. Por exemplo, poderia ser utilizado um disco SCSI 15000 RPM para o journal de um sistema de arquivos localizado em discos SATA2 7200 RPM. Como o sistema testado não possuia os recursos para esse tipo de configuração, ela não foi considerada.

Resultados

O primeiro gráfico mostra o tempo para leitura de uma mensagem pelo número de processos de escrita simultâneos. Os valores do tempo estão em milissegundos, e quanto menor esse valor, mais rápido é o sistema de arquivos para leitura de mensagens. O número de processos de escrita simultâneos é proporcional à quantidade de mensagens localizada nas caixas postais.

O segundo gráfico mostra o tempo para entrega de uma mensagem pelo número de processos de escrita simultâneos. Esse tempo é uma média entre os valores obtidos por cada processo de escrita. Obviamente o critério é o mesmo do primeiro gráfico: quanto menor o tempo, mais rápido é o sistema de arquivos para entrega de mensagens.

Os arquivos de log do fsbench estão disponíveis para download neste link.

Conclusão

O primeiro ponto importante revelado pelos gráficos é a coerência em relação aos resultados do EXT3. Os três métodos de journaling se comportaram como indica a teoria quanto ao desempenho de escrita. Quem saiu ganhando foi o método writeback, seguido do ordered e do journal.

Quando o assunto é desempenho de leitura, o método ordered justificou o motivo de ser a escolha padrão, obtendo o melhor resultado nesse critério.

Comparando com os outros sistemas de arquivos, o EXT3 surpreendeu, se respeitarmos o fato dele, até pouco tempo atrás, demonstrar enorme inferioridade no desempenho de leitura em relação aos sistemas de arquivos XFS e ReiserFS. O método ordered parece ser a melhor escolha.

Apesar do XFS, em geral, apresentar o melhor desempenho entre todos os sistemas de arquivos, ele mostrou uma preocupante degradação de performance na leitura de mensagens, proporcional ao número de processos de escrita simultâneos e conseqüente quantidade de arquivos. Isso indica que o XFS pode não ser a melhor escolha para servidores de e-mail de larga escala, cujas caixas postais ultrapassam milhares de mensagens na ordem dos gigabytes.

O ReiserFS 3.6 teve um bom desempenho de escrita, similar ao método writeback do EXT3. A leitura de mensagens demonstrou estabilidade, sem perder performance a medida que aumentava o número de processos simultâneos de escrita. Porém, a performance de leitura do ReiserFS foi inesperadamente inferior ao método ordered do EXT3. Mérito do EXT3.

Já o JFS, mesmo com uma boa performance de escrita, revelou-se bem inferior nos testes de leitura de mensagens, o que o torna desaconselhável para servidores de e-mail que usam o formato Maildir.

No confronto destes resultados com os obtidos pelos testes originais, feitos pelo autor do fsbench, o EXT3 mostrou uma grande evolução e parece ter entrado na briga para disputar a preferência no cenário discutido. O sistema de arquivos XFS mostrou praticamente os mesmos resultados, inclusive confirmando o problema de performance para ler grandes quantidades de arquivos.

O ReiserFS 3 parece não ter demonstrado muita evolução nos últimos anos, e por esse e outros motivos, está claramente perdendo espaço para o EXT3. Prova disso é a decisão da Novell de tornar o EXT3 padrão em sua distribuição, o SuSE Linux Enterprise Server, que historicamente adotava o ReiserFS. Também tem a Red Hat, que incluí suporte apenas ao EXT3 desde a versão 4 do Red Hat Enterprise Linux.

Neste momento, os grupos fanáticos de cada sistema de arquivos estão concentrando argumentos para uma nova batalha, envolvendo as próximas versões dos sistemas de arquivos. Destaque para o ReiserFS4 e o EXT4. Enquanto isso, o restante da comunidade senta e assiste.

Referências

Guenter, Bruce (14-05-2004). Benchmarking Maildir Delivery on Linux Filesystem. Untroubled.org. Acessado em 10-01-2008.
Wikipédia (06-10-2007). EXT3. Acessado em 11-01-2008.
eComStation.RU (08-05-2005). Overview of the JFS Filesystem. Acessado em 12-01-2008.