Como melhorar a performance de escrita em HD?

[im-alexandre]

Meu servidor do postgres tem um HD. Está pedindo 10 dias para incluir os registros. Alguma dica de como acelerar o processo de escrita no postgresql?

[cuducos]

Depende muito.

Você pode passar as configurações (processador, memória) do computador rodando o processo, bem como as opções utilizadas no comando transform (por exemplo, --max-parallel-db-queries e --batch-size)? Ou, também, ir variando essas duas configurações e ver como otimizar o processo para o seu equipamento.

Além disso, o que eu faço, vez ou outra:

• crio uma máquina virtual parruda na nuvem (dessas que custariam 100 USD/mês)
• instalo o PostgreSQL lá
• rodo o processo
• baixo um dump do PostgreSQL

Isso tudo não levara uma manhã, e, vez o ou outra, o provedor de nuvem nem cobra por ser muito pouco tempo (mesmo para uma máquina cara).

Talvez com esse link vc consiga uns créditos na DigitalOcean. Lá, para fazer esse processo, normalmente uso esse:

[cuducos]

Complementando com coisas que pensei e não escrevi:

• Como a velocidade de escrita em HD e SSD é gritante, não tem muito o que fazer (é uma limitação de hardware)
• Minha sugestão de gerar um dump é que para, na hora de carregar, ser uma tarefa única (ou seja, não compete com recursos do processamento dos dados), mas vai ser lento mesmo… são quase 150Gb

[im-alexandre]

Eu estou rodando em um servidor com um processador Intel(R) Xeon(R) Bronze 3106 (32 núcleos lógicos) e 32GB de RAM. Ele tem um HD de 4TB, mas não tem SSD. Tenho que rodar on-premise mesmo.

Utilizei os parâmetros default mesmo. --max-parallel-db-queries=32 e --batch-size=8192.
Vou rodar na nuvem ou no meu notebook e exportar só o que eu preciso mesmo.
Vou variando esses parametros e usando o sample para comparar o tempo. Depois mando aqui.

Valeu pela ajuda tão rápida! Admirando ainda mais o seu trabalho aqui!!!

[cuducos]

Vou variando esses parametros e usando o sample para comparar o tempo. Depois mando aqui.

Perfeito! Conta como foi que tô curioso.

Com uma máquina dessa, com certeza o gargalo é a escrita mesmo.

[oristides]

Oi,

Também queria saber como é essa questão de performance, contratei uma maquina bem parruda na AWS e aumentei os parámetros --max-parallel-db-queries=50 mas ainda assim a taxa de apenas 466 it/segundo o que deixa o processo tudo para ser completado em 55 horas, será que esotu fazendo algo errado?

Obrigado!

[cuducos]

contratei uma maquina bem parruda na AWS

Difícil dizer sem saber o que é essa máquina parruda e como está teu processo.

• O que é uma máquina parruda para você? Quantos processadores? Quanto de memória? SSD ou HD? Storage na mesma instância?
• Execução e banco de dados na mesma máquina? Na mesma região?
• Etc.

Fora isso, como falei antes:

ir variando essas duas configurações e ver como otimizar o processo para o seu equipamento.

Você mencionou que colocou as queries paralelas para 50. Testou outros valores? Quais? Testou mudar o tamanho do lote (batch size)? Com quais valores?

[oristides]

Máquina parruda, das carateristicas que vocẽ comentou antes:

Uma t3a.2xlarge
8 vCPU
16gbs ram
200gb ssd

Execução e banco de dados na mesma máquina? Na mesma região? Sim, e sim. North Virginia

• para queries paralelas testei varios valores default, 50 , 64, 80
• para batch também testei: default, 15000, 80000, 150000

Também testei valores com e sem --no-pŕivacy

O resultado sempre está dando igual.. tem uma tarxa de 3000it/sec e passa a 400 it/se. Por isso queria entender se estou fazendo alguma coisa errada.

[cuducos]

200gb ssd

Talvez seja pouco: considerando sistema operacional, instalação do Postgres, dados de fownload, swap etc. Como diz a documentação: É necessário cerca de 150Gb disponíveis de espaço em disco para armazenar os dados. Você deve estar operando nesse limite. No exemplo que dei, uso 320Gb de SSD.

para queries paralelas testei varios valores default, 50 , 64, 80

Acho que a variação aqui foi pouca. Normalmente teste valores exponenciais: o padrão acho que é 32, você testou 64, mas acho que pode continuar no exponencial de 128 e 256, pelo menos.

para batch também testei: default, 15000, 80000, 150000

Acho bons os intervalos. Com isso e a variação de paralelismo no banco de dados, você deve conseguir uma velocidade maior. Eu deveria ter anotado os valores que usei. Mas precisamos de um benchmark mais formal numa máquina desse padrão mesmo… (os valores que uso são isso: acerto e erro; acerto, erro e esquecimento, no caso hahaha…).

Uma ciclo que faço é:

• criar um sample (ver ./minha-receita sample --help)
• abrir o htop
• importar o sample
• observar o que está sobrecarregando (se é memória ou processador, qual processo tá sofrendo mais etc)
• anotar, variar os argumentos de paralelismo e tamanho do lote
• repetir

[matheus-rossi]

Fala pessoal

Estou usando o projeto para um trabalho pessoal e entendendo todo o contexto, vim compartilhar um teste que vou fazer (assim que o servidor ftp me permitir 🙃).

Vi todo esse problema do tamanho dos dados pós inserção no postgres e também de questões de performace.

Vou testar uma abordagem diferente, eis o que vou fazer:

Após baixar os dados em CSV, vou processar eles e salvar em formato parquet (otimizado). Como a API é apenas para leitura dos dados, penso em usar o postgres apenas como uma interface para consulta desses dados.

Artigo de Exemplo

Tendo esses dados gravados em formato otimizado para leitura, talvez seja possível reduzir o problema de tempo de gravação e também de custos (embora a arquitetura deveria ser repensada).

De qualquer modo, assim que eu finalizar os testes, volto aqui para compartilhar mais detalhes

[cuducos]

assim que o servidor ftp me permitir

Você pode (se confiar em mim hehehe) baixar do mirror extra-oficial que mantenho.

Curiosíssimo para ver o resultado desse experimento — muito obrigado, @matheus-rossi : )

[cuducos]

@matheus-rossi, se ajudar, criei o arquivo Parquet aqui com base no banco de dados de produção, ficou com 25Gb (o banco em produção ocupa 107Gb).

Usei o ogr2ogr, como mencionado no artigo que vc linkou 💜

O que não consegui ainda é criar um Dockerfile com Postgres e o FDW do Parquet (meio que travei aqui). Mas um passo por vez : )

[cuducos]

Fechado por inatividade.