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

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!

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!

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.

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.

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.

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.

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.

Vi que me lembrei que um FreeBSD aprimorado lhe dará um pouco mais de desempenho, em comparação com outros sistemas operacionais. Embora eu tenha certeza de que essa informação está desatualizada e provavelmente seja um mito em primeiro lugar. Mas você pode experimentar, no entanto, consulte esta diretriz para as configurações do kernel: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html