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


20

Estou curioso para saber se alguém já fez alguma experimentação ou comparação entre sistemas de arquivos e desempenho de 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 no banco de dados?

Se você estiver procurando por uma pergunta relacionada ao desempenho geral do sistema de arquivos / banco de dados, esta postagem contém algumas informações boas.

No entanto, eu gostaria de receber o máximo de conselhos sobre desempenho de pastilhas , em vez de ler o desempenho possível. Obrigado por todas as ótimas respostas!


7
O melhor sistema de arquivos seria mais memória? ;)
Oskar Duveborn

2
+1 para Oskar. Acabamos de passar de uma configuração de servidor em que a RAM era ~ 33% do tamanho total do banco de dados para uma nova máquina em que a RAM total era maior que o tamanho do banco de dados. Agora podemos armazenar em cache todo o banco de dados na memória. Nossa consulta SQL mais lenta agora é 2 ordens de magnitude mais rápida.
21411 KevinRae

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.

Em resumo: não há resposta curta.

Mas vou tentar summerize:

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

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


4
Concordado, esse é o tipo de tópico que Greg aborda muito bem. Há um capítulo de amostra em packtpub.com/sites/default/files/… se você gostaria de avaliar antes de pedir emprestado ou comprar o livro.
sciurus

11
Engraçado, quando eu estava tendo esse problema, o livro não existia. Agora, sou muito grato pelo esforço que Greg colocou nesse livro.
Eliash

Eu comprei outra cópia apenas para homenagear este grande trabalho :-) #
314

6

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

Os testes de desempenho mostram que geralmente o XFS oferece o melhor desempenho. Existem alguns problemas de estabilidade quando você alcança cenários de disco muito próximo do cheio, mas, desde que você monitore se isso não acontece, ele oferecerá um desempenho um pouco melhor.

Em teoria, você não precisa de um sistema de arquivos de registro em 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ê realmente deve sempre ter um sistema de arquivos de registro em diário de metadados.


4
Você pode querer / não usar o XFS para armazenar um banco de dados, ou seja, porque (quando necessário) zerará os blocos que não podem ser recuperados.
Avery Payne

4

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

  1. O diário redundante aumenta a quantidade de atividade do disco

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

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

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

Volumes contendo arquivos de banco de dados normalmente terão um pequeno número de arquivos grandes. Os servidores DBMS normalmente têm 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 minimizariam o armazenamento em cache de dados redundantes. Números maiores seriam apropriados para sistemas como data warehouses que faziam muitas leituras sequenciais. Se possível, ajuste o tamanho do bloco de alocação do sistema de arquivos para ter o mesmo tamanho da leitura de vários blocos em que o DBMS está definido.

Alguns sistemas de gerenciamento de banco de dados podem trabalhar com partições de disco bruto. Isso fornece graus variados 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 os metadados do sistema de arquivos, a economia na E / S do disco era bastante significativa. 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 ser colocados fisicamente volumes de disco separados para os dados. Se o seu banco de dados for grande e principalmente somente leitura (por exemplo, um data warehouse), pode haver um caso de colocá-lo nos volumes RAID-5, se isso não atrasar indevidamente o processo de carregamento.

O cache de write-back em um controlador pode oferecer uma melhora no desempenho às custas da criação de alguns modos de falha (razoavelmente improváveis, mas possíveis) em que os dados podem ser corrompidos. O maior ganho 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 desativar o cache de write-back nos volumes de log. Os logs terão melhor integridade dos dados e uma única falha não poderá remover os volumes de log e de dados. Isso permite restaurar a partir de um backup e avançar dos logs.


O diário de dados diminui o desempenho; os metadados do diário devem ter, no pior dos casos, um impacto mínimo e, provavelmente, quase nenhum. Não registrar metadados no diário é desaconselhável.
NiXar 29/05/2009

Eu acho que você não entendeu o artigo. Qualquer sistema de arquivos possui metadados do sistema de arquivos e qualquer tráfego de disco envolve a leitura ou gravação disso. Os computadores modernos geralmente têm RAM suficiente para armazenar em cache facilmente esses metadados do sistema de arquivos, mas as máquinas mais antigas não. Isso significava que os acessos ao disco incorriam em uma sobrecarga de E / S adicional significativa (o número frequentemente citado para Oracle era um desempenho de 30% nas partições brutas) para ler ou atualizar os metadados do sistema de arquivos. Em um sistema moderno com mais RAM, é mais provável que os metadados do sistema de arquivos sejam armazenados em cache, portanto, a sobrecarga é menor.
ConcernedOfTunbridgeWells

Isso contém alguns bons conselhos gerais, mas diminuí a votação porque também contém informações irrelevantes ou incorretas para o postgresql e os sistemas de arquivos com registro em diário modernos.
sciurus

3

Fiz um relatório tão detalhado, mas é apenas em francês . Se você lê francês ou está 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 planejador de E / S do Linux tem muito pouca importância para desempenhos e o sistema de arquivos apenas um pouco. Portanto, se você estiver com pressa, basta escolher o padrão. Eu escolhi o JFS.


2

O sistema de arquivos é apenas parte do problema. Você pode obter um aumento significativo no desempenho alterando seu agendador de E / S. Felizmente, isso é bastante fácil de testar, pois você pode alterar o agendador de E / S imediatamente. Sugiro tentar cada um deles por alguns dias sob carga típica e ver qual dá o melhor desempenho.


Meus benchmarks mostraram muito pouca alteração ao alterar o agendador de E / S, provavelmente porque todo DBMS já possui seu próprio agendador.
Bortzmeyer

O MySQL lida muito melhor sob alta carga usando o agendador de prazos.
David Pashley

2

Eu fiz alguns testes há alguns meses:

Eu tinha um pequeno programa de teste que criou 50 threads, em que cada thread inseria 1000 (ou se fosse 10000) linhas na mesma tabela.

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

Mas ter o pg___xlog em um ramdisk de software não é uma opção: se você perder o conteúdo do diretório pg_xlog, o postgres não será iniciado. (Mas existem ramdisks de hardware com backup de bateria que podem ser interessantes.)

IMHO: Use o sistema de arquivos com o qual você se sente mais confortável para os arquivos de banco de dados. Mova o pg_xlog (com um link simbólico, consulte a documentação) para o dispositivo mais rápido possível que você possui.


11
O pgbench faz algo semelhante e está incluído na maioria das instalações.
Avery Payne

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.