PostgreSQL - Se eu executar várias consultas simultaneamente, em que circunstâncias eu veria uma aceleração? Em que circunstâncias eu veria uma desaceleração?

Abordo todos vocês humildemente como alguém que NÃO é um DBA, e tenho certeza de que minha pergunta está repleta de deficiências conceituais e "depende de" minas terrestres. Também tenho certeza de que todos vocês que escolherem responderão querer muito mais detalhes específicos do que eu posso fornecer atualmente.

Dito isto, estou curioso sobre o seguinte cenário em geral:

• Digamos que eu tenha duas consultas não triviais.
• A consulta 1 requer 2 minutos para ser concluída em média.
• A consulta 2 requer 5 minutos para ser concluída em média.

Se eu executá-los em série, um após o outro, espero que demore 7 minutos para concluir, em média. Isso é razoável?

Mais do que isso, no entanto, e se eu executar as duas consultas simultaneamente? Duas conexões separadas ao mesmo tempo.

• Em que condições eu esperaria ver uma aceleração? (Tempo total <7 minutos)
• Em que condições eu esperaria ver uma desaceleração? (Tempo total> 7 minutos)

Agora, se eu tivesse 1.000 consultas não triviais em execução simultaneamente, tenho um palpite de que isso resultaria em uma desaceleração geral. Nesse caso, onde estaria o gargalo? Processador? RAM? Drives?

Novamente, eu sei que é provavelmente impossível responder à pergunta precisamente sem saber detalhes (o que eu não tenho.) Estou procurando algumas diretrizes gerais para pensar ao fazer as seguintes perguntas:

• Sob quais circunstâncias as consultas simultâneas resultam em uma aceleração geral?
• Sob quais circunstâncias as consultas simultâneas resultam em uma desaceleração geral?

Se eu executá-los em série, um após o outro, espero que demore 7 minutos para concluir, em média. Isso é razoável?

Se eles usarem conjuntos de dados não relacionados, então sim.

Se eles compartilharem um conjunto de dados e o cache estiver frio para a primeira consulta e a consulta estiver principalmente ligada à E / S, a segunda poderá ser concluída em alguns momentos. Você precisa considerar os efeitos de armazenamento em cache ao lidar com análise de desempenho e tempo de consulta.

Mais do que isso, no entanto, e se eu executar as duas consultas simultaneamente? Duas conexões separadas ao mesmo tempo.

"Depende".

Se ambos estivessem usando varreduras seqüenciais da mesma tabela, no PostgreSQL seria uma grande conquista de desempenho devido ao seu suporte a varreduras seqüenciais sincronizadas.

Se eles compartilharem os mesmos índices, provavelmente se beneficiarão das leituras uns dos outros no cache.

Se forem independentes e tocarem em dados diferentes, poderão competir pela largura de banda de E / S; nesse caso, poderão levar a mesma quantidade de tempo que a execução sequencial. Se o subsistema de E / S se beneficiar da simultaneidade (maior rendimento líquido com mais clientes), o tempo total poderá ser menor. Se o subsistema de E / S manipular a concorrência de maneira inadequada, eles poderão demorar mais do que executá-los sequencialmente. Ou eles podem não estar vinculados à E / S; nesse caso, se houver uma CPU livre para cada um deles, eles poderão executar como se o outro não estivesse em execução.

Depende muito da configuração do hardware e do sistema, do conjunto de dados e das próprias consultas.

Agora, se eu tivesse 1.000 consultas não triviais em execução simultaneamente, tenho um palpite de que isso resultaria em uma desaceleração geral. Nesse caso, onde estaria o gargalo? Processador? RAM? Drives?

Sim, isso provavelmente atrasaria as coisas por vários motivos.

• As próprias despesas gerais do PostgreSQL na coordenação entre processos, gerenciamento de transações e bloqueios, gerenciamento de buffer etc. Isso pode ser um custo bastante alto, e o PostgreSQL não é realmente projetado para uma alta contagem de clientes - funciona melhor se você trabalhar em fila .

• Competição por memória de trabalho, cache, etc.

• Sobrecarga de agendamento do sistema operacional, pois manipula 1000 processos concorrentes, todos desejando intervalos de tempo. Hoje em dia, os sistemas operacionais modernos têm agendadores rápidos.

• E / S debulhando. A maioria dos sistemas de E / S possui uma contagem máxima de clientes de desempenho. Às vezes é 1, ou seja, é melhor com apenas um cliente, mas geralmente é mais alto. Às vezes, o desempenho diminui novamente acima do limite. Às vezes, apenas atinge um platô.