Qual é o melhor sistema de arquivos Linux para MySQL (InnoDB)?

Eu tentei procurar benchmark no desempenho de vários sistemas de arquivos com o MySQL InnoDB, mas não consegui encontrar nenhum.

Minha carga de trabalho de banco de dados é o OLTP típico baseado na Web, cerca de 90% de leitura e 10% de gravação. IO aleatório.

Entre os sistemas de arquivos populares, como ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc., qual deles você acha que é o melhor para o MySQL?

Quanto você valoriza os dados?

Sério, cada sistema de arquivos tem suas próprias vantagens e desvantagens. Antes de ir muito além, sou um grande fã do XFS e do Reiser, embora eu geralmente execute o Ext3. Portanto, não existe um viés real do sistema de arquivos em funcionamento aqui, apenas informando ...

Se o sistema de arquivos for pouco mais que um contêiner para você, escolha o que lhe fornecer os melhores tempos de acesso.

Se os dados tiverem um valor significativo, convém evitar o XFS. Por quê? Porque se ele não pode recuperar uma parte de um arquivo que está no diário que vai zerar os blocos e fazer un recuperável de dados. Esse problema foi corrigido no Linux Kernel 2.6.22 .

O ReiserFS é um ótimo sistema de arquivos, desde que nunca trate com força . A recuperação do diário funciona bem, mas se, por algum motivo, você perder suas informações de partição, ou se os blocos principais do sistema de arquivos forem destruídos, poderá haver um dilema se houver várias partições ReiserFS em um disco - porque o mecanismo de recuperação basicamente varre o disco inteiro, setor por setor, procurando o que "pensa" é o início do sistema de arquivos . Se você tem três partições com o ReiserFS, mas apenas uma é explodida, você pode imaginar o caos que isso causará, pois o processo de recuperação une uma bagunça Frankenstein dos outros dois sistemas ...

O Ext3 é "lento", em "Eu tenho 32.000 arquivos e leva tempo para encontrá-los todos em execução ls". Se você tiver milhares de pequenas mesas temporárias em todos os lugares, sentirá um pouco de tristeza. As versões mais recentes agora incluem uma opção de índice que reduz drasticamente o percurso do diretório, mas ainda pode ser doloroso.

Eu nunca usei o JFS. Só posso comentar que todas as resenhas que já li foram algo como "sólido, mas não o garoto mais rápido do quarteirão". Pode merecer investigação.

Chega dos Contras, vamos olhar para os Prós:

XFS:

• grita com arquivos enormes, rápido tempo de recuperação
• pesquisa de diretório muito rápida
• Primitivas para congelar e descongelar o sistema de arquivos para dumping

ReiserFS:

• Acesso altamente otimizado a arquivos pequenos
• Empacota vários arquivos pequenos nos mesmos blocos, economizando espaço no sistema de arquivos
• recuperação rápida, rivaliza com os tempos de recuperação do XFS

Ext3:

• Tentado e verdadeiro, com base no código Ext2 bem testado
• Muitas ferramentas para trabalhar com ele
• Pode ser remontado como Ext2 em uma pitada para recuperação
• Pode ser reduzido e expandido (outros sistemas de arquivos podem ser expandidos apenas)
• As versões mais recentes podem ser expandidas "ao vivo" (se você for tão ousado)

Então você vê, cada um tem suas próprias peculiaridades. A questão é: qual é a menos peculiar para você?

Também pode ser interessante notar que você pode executar o InnoDB sem um sistema de arquivos e melhorar o desempenho sem sobrecarga do sistema de arquivos. Não tenho certeza se recomendaria, mas já o usei sem problemas.

Dispositivos brutos do InnoDB

Além disso, se você estiver executando 90% das leituras e 10% das gravações, a menos que precise da capacidade transacional do InnoDB, poderá migrar para o MyISAM para obter melhor desempenho de leitura.

As respostas aqui estão seriamente obsoletas e precisam ser atualizadas, pois isso está aparecendo nos resultados do Google.

Para ambientes de produção, XFS. Toda vez. O XFS é registrado no diário e sem bloqueio. Verifique se você possui as seguintes variáveis ​​para um banco de dados MySQL moderno (2011/2012) usando o InnoDB na produção:

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

Não use EXT3 ou mesmo EXT4. Um dia o BTRFS chegará lá.

EXT3, e talvez EXT4, trava no nível do inode, não é inteligente!

Fontes: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Entendendo o MySQL Internals de Sasha Pachev - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Alguns kits de oscilação, tentativa e erro.

EDIT: Uma atualização. EXT4 parece estar indo muito bem a partir de meados de 2013! O BTRFS ainda não é uma boa opção. E o RHEL pode muito bem tornar o XFS o novo sistema de arquivos padrão. Novamente, NÃO use EXT3.

A versão curta é que a mais próxima de uma recomendação que eu já vi o MySQL fazer em sistemas de arquivos é o XFS, por mais que ext3 deva estar bem, ext4 promete ser uma boa melhoria, mas ainda não é bastante estável, embora deva ser anterior ao final do ano.

Se você estiver executando sistemas de arquivos em cluster CXFS, OCFS2 e GFS deverão estar ok.

Eu alertaria fortemente contra qualquer derivado Reiser e o JFS, embora antes agradável tenha sido derrotado pelo XFS e pelo ext4, que são mais amplamente implementados.

Não é provável que faça muita diferença. Vá com o que sua distribuição usar como padrão, desde que seja suficiente.

Gaste seu esforço ajustando outras coisas - obtenha memória RAM suficiente - obtenha um controlador de ataque que não seja ruim - e corrija o uso manco (ab) do banco de dados do aplicativo (NB: este é o principal culpado na maioria dos casos em que ainda não o fez) foi feito).

Considere, no entanto, com cuidado, o sistema de arquivos em que você colocou o mysql tmpdir; isso afetará o desempenho, principalmente as consultas que executam filesort () s baseadas em disco (consulte EXPLAIN para obter mais detalhes).

Eu acho que um sistema de arquivos que suporta alocação atrasada é realmente útil aqui, pois você pode evitar E / S completamente para arquivos de vida curta quando houver memória RAM suficiente para mantê-los no cache. O XFS, por exemplo, não se incomoda em escrever arquivos que são excluídos e fechados antes de serem alocados.

É claro que colocar um tmpdir em um tmpfs é atraente do ponto de vista do desempenho, mas leva ao risco de esgotar o espaço e ter consultas que seriam bem-sucedidas (embora com arquivos temporários em disco usados) falhem.

Não estou encontrando nenhum artigo recente com "comparações" de benchmark no MySQL em execução em vários sistemas de arquivos. Dada a carga de trabalho que você descreve, duvido que a fragmentação no nível do arquivo seja um problema. Sem uma referência formal, não posso dizer nada que você deva ter autoridade, mas meu instinto diz que todo sistema de arquivos que você mencionou acima terá um desempenho aproximado no mesmo estádio (ou seja, todos na mesma ordem de magnitude para números de desempenho) .

O banco de dados está realmente executando o programa, uma vez que o sistema de arquivos está apenas gerenciando grandes extensões que o mecanismo de armazenamento está acessando.

Ainda assim, seria interessante fazer um resumo do desempenho com todos esses sistemas de arquivos. (Porém, tenho pouco entusiasmo pelo MySQL, por isso não vou aceitá-lo. Benchmarking Postgres, OTOH, pode ser interessante ...)

IMHO os FSs dignos de nota disponíveis para o Linux são:

XFS (baixa velocidade de leitura) conhecido por ser leve nos recursos do sistema e rápido com arquivos grandes, mas ruim para lidar com muitos arquivos pequenos.

O ReiserFS (baixa velocidade de gravação) não é muito gentil com os recursos do sistema, mas funciona muito bem com muitos arquivos pequenos.

EXT3 fica no meio, com desempenho aceitável em todos os campos (a razão pela qual é considerado o FS padrão do linux).

Ainda não usei o EXT4 e nem o ReiserFS4, mas observei alguns benchmarks e o ReiserFS parece ter o melhor desempenho em velocidade de leitura, o que você disse ser o mais importante para você.

Dê uma olhada no seguinte: ReserFS4 X Ext4 X Ext3

Eu recomendaria o Ext3 por sua estabilidade, segurança e maturidade, mas se a velocidade de leitura é o mais importante para você, considere o ReiserFS.

Lembre-se de que você também deve considerar o uso da CPU, estabilidade, segurança etc. antes de escolher um FS.

E, é claro, fazer um piloto, testar e fazer comparações em seu ambiente específico é sempre a melhor maneira de dizer o que funcionará melhor para você.

PS: Eu teria postado mais benchmarks, mas não posso postar mais de um link.