Qual é o melhor sistema de arquivos para o desempenho de inserção no PostgreSQL?

20

Estou curioso para saber se alguém fez alguma experimentação ou comparação entre os sistemas de arquivos e o desempenho do banco de dados. No Linux, estou me perguntando qual é o sistema de arquivos ideal para um banco de dados postgres. Além disso, quais configurações (inode, etc) são ideais para isso? Isso é algo que pode diferir drasticamente com base nos dados do banco de dados?

Se você estiver procurando por uma pergunta relacionada ao desempenho geral do sistema de arquivos / banco de dados, este post tem boas informações.

No entanto, gostaria de obter o máximo de aconselhamento sobre o desempenho do insert em oposição ao desempenho de leitura possível. Obrigado por todas as ótimas respostas!

    
por Elijah 29.05.2009 / 10:20

8 respostas

14

Compre uma cópia do "postgresql high performance" de Greg Smith. É um ótimo Livro e dois ou mais capítulos são sobre Hardware de Disco e sistemas de arquivos. Você aprenderá muito.

Resumindo: não há resposta curta.

Mas vou tentar passar o verão:

  • não use ext2 até saber o que você está fazendo.
  • com ext3, tenha cuidado com picos de pontos de verificação devido a chamadas fsync, consulte a página 113 e 82 e 79
  • use ext4 ou xfs
  • existem outras opções

Mas, como você está realmente se perguntando qual FS usar, você deveria ler o livro!

    
por 30.04.2011 / 00:45
6

Primeiro de tudo, você quer um sistema de arquivos confiável primeiro e um segundo rápido. Que exclui algumas opções ...

O teste de desempenho mostra que, com frequência, o XFS oferece o melhor desempenho. Há alguns problemas de estabilidade quando você alcança cenários de disco muito próximo a todos, mas, desde que você monitore para que isso não aconteça, ele terá um desempenho um pouco melhor.

Em teoria, você não precisa de um sistema de arquivos de registro no diário para o diretório pg_xlog, mas a diferença de velocidade geralmente é tão pequena que simplesmente não vale a pena. Para o diretório de dados, você deve sempre ter um sistema de arquivos de journaling de metadados.

    
por 05.06.2009 / 10:39
4

Os sistemas de gerenciamento de banco de dados implementam seu próprio diário através dos logs do banco de dados, portanto, a instalação desse DBMS em um sistema de arquivos com lançamento diário prejudica o desempenho por meio de dois mecanismos:

  1. O journalling redundante aumenta a quantidade de atividade do disco

  2. O layout do disco físico pode ser fragmentado (embora alguns sistemas de arquivos com lançamento diário tenham mecanismos para limpar isso).

  3. Muita atividade de disco pode preencher o diário, causando condições espúrias de 'disco cheio'.

Eu tenho visto uma instância há alguns anos onde isso foi feito no sistema de arquivos LFS em uma instalação do Baan em uma caixa HP / UX. O sistema teve problemas persistentes de desempenho e corrupção de dados que não foram diagnosticados até que alguém descobriu que os sistemas de arquivos foram formatados com o LFS.

Volumes contendo arquivos de banco de dados normalmente terão um pequeno número de arquivos grandes. Os servidores DBMS normalmente terão uma configuração que configura quantos blocos são lidos em uma única E / S. Números menores seriam apropriados para sistemas de processamento de transações de alto volume, pois eles minimizariam o armazenamento em cache de dados redundantes. Números maiores seriam apropriados para sistemas como armazéns de dados que faziam muitas leituras sequenciais. Se possível, ajuste o tamanho do bloco de alocação do sistema de arquivos para o mesmo tamanho que o bloco múltiplo lido para o qual o DBMS está configurado.

Alguns sistemas de gerenciamento de banco de dados podem funcionar com partições de disco bruto. Isso dá vários graus de ganho de desempenho, geralmente menos em um sistema moderno com muita memória. Em sistemas mais antigos, com menos espaço para armazenar em cache metadados do sistema de arquivos, a economia na E / S de disco era bastante significativa. As partições brutas tornam o sistema mais difícil de gerenciar, mas fornecem o melhor desempenho disponível.

Os volumes RAID-5 incorrem em mais sobrecarga de gravação que os volumes RAID-10, portanto, um banco de dados ocupado com muito tráfego de gravação terá um desempenho melhor (geralmente muito melhor) em um RAID-10. Os logs devem colocar volumes de disco fisicamente separados nos dados. Se o seu banco de dados for grande e principalmente somente leitura (por exemplo, um data warehouse), pode haver um caso para colocá-lo em volumes RAID-5, se isso não retardar indevidamente o processo de carregamento.

O cache de write-back em um controlador pode dar a você uma vitória em termos de desempenho, em detrimento da criação de alguns modos de falha (razoavelmente improvável, mas possível) nos quais os dados podem ser corrompidos. A maior conquista de desempenho para isso é em cargas de acesso altamente aleatórias. Se você quiser fazer isso, considere colocar os logs em um controlador separado e desabilitar o cache write-back nos volumes de log. Os logs terão, então, uma melhor integridade de dados e uma única falha não poderá eliminar os volumes de log e de dados. Isso permite restaurar a partir de um backup e avançar dos logs.

    
por 29.05.2009 / 11:14
3

Eu fiz um relatório tão detalhado, mas ele é somente em francês . Se você ler francês ou estiver satisfeito com as ferramentas de tradução automática ... Você pode reutilizar a metodologia e executá-la por conta própria.

Resumo executivo: usei o pgbench. O escalonador de E / S do Linux tem pouca importância para performances e o sistema de arquivos apenas um pouco. Então, se você está com pressa, basta escolher o padrão. Eu escolhi o JFS.

    
por 09.06.2009 / 11:16
2

O sistema de arquivos é apenas parte do problema. Você pode obter um aumento significativo de desempenho alterando seu agendador de I / O. Felizmente, isso é bastante fácil de testar, já que você pode alterar o agendador de IO na hora. Eu sugeriria testar cada um por alguns dias em carga típica e ver qual apresenta o melhor desempenho.

    
por 05.06.2009 / 10:46
2

Eu fiz alguns testes há alguns meses:

Eu tive um pequeno programa de teste que criou 50 threads, onde cada thread inseriu 1000 (ou se foram 10000) linhas na mesma tabela.

  • Com o banco de dados no EXT3 e um RAID5 de 4 discos, demorou 50 segundos.
  • Com a tabela no ramdisk (usando tablespace), ainda demorou 50 segundos. A razão pela qual não foi mais rápido é que tudo está logado no diretório pg_xlog que ainda está no mesmo RAID 5.
  • Eu movi o pg_xlog para um RAID0 de 4 discos (faixa) e o mesmo programa foi executado em 40 segundos.
  • Para fins de teste, mudei o pg_xlog para o ramdisk e tinha todo o resto no RAID do disco EXT3 4. O programa foi concluído após menos de 5 segundos.

Mas ter o pg

por 15.06.2009 / 05:02
1

Depois de alguns anos na trincheira, minha resposta é ZFS e SmartOS.

Este é um documento sobre os pontos de referência: link

    
por 10.04.2015 / 05:50
0

Eu vi que lembrei que um FreeBSD aprimorado lhe dará um pouco mais de performance em oposição a outros sistemas operacionais. Embora eu tenha certeza de que esta informação está desatualizada e provavelmente um mito em primeiro lugar. Mas você pode experimentá-lo mesmo assim, veja esta diretriz para as configurações do kernel: link

    
por 05.06.2009 / 11:38