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 decidirem responder vão querer muito mais detalhes do que posso fornecer atualmente.
Dito isso, estou curioso sobre o seguinte cenário em geral:
- Digamos que eu tenha duas consultas não triviais.
- A consulta 1 requer em média 2 minutos para ser concluída.
- A consulta 2 requer em média 5 minutos para ser concluída.
Se eu executá-los em série, um após o outro, espero que leve 7 minutos para ser concluído 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 um aumento de velocidade? (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 provavelmente estaria o gargalo? Processador? BATER? Dirige?
Mais uma vez, sei que provavelmente é impossível responder à pergunta com precisão sem conhecer os detalhes (o que não tenho). Estou procurando algumas diretrizes gerais para pensar ao fazer as seguintes perguntas:
- Em que circunstâncias as consultas simultâneas resultam em uma aceleração geral?
- Em que circunstâncias as consultas simultâneas resultam em uma desaceleração geral?
Se eles usarem conjuntos de dados não relacionados, sim.
Se eles compartilharem um conjunto de dados e o cache estiver frio para a primeira consulta e a consulta for principalmente vinculada a E/S, a segunda poderá ser concluída em instantes. Você precisa considerar os efeitos de cache ao lidar com análise de desempenho e tempo de consulta.
"Depende".
Se ambos estivessem usando varreduras sequenciais da mesma tabela, no PostgreSQL seria uma grande vitória de desempenho por causa de seu suporte para varreduras sequenciais sincronizadas.
Se eles compartilhassem os mesmos índices, provavelmente se beneficiariam 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 e, nesse caso, podem levar o mesmo tempo que a execução sequencial. Se o subsistema de E/S se beneficiar da simultaneidade (taxa de transferência de rede mais alta com mais clientes), o tempo total poderá ser menor. Se o subsistema de E/S lidar mal com a simultaneidade, eles podem demorar mais do que executá-los sequencialmente. Ou eles podem não estar vinculados a E/S; nesse caso, se houver uma CPU livre para cada um, eles poderão ser executados 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.
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 foi realmente projetado para altas contagens de clientes - funciona melhor se você enfileirar trabalhos .
Competição por memória de trabalho, cache, etc.
Sobrecarga de agendamento do sistema operacional enquanto ele manipula 1.000 processos concorrentes, todos querendo fatias de tempo. Muito menor hoje em dia, os sistemas operacionais modernos têm agendadores rápidos.
Debulha de E/S. A maioria dos sistemas de E/S tem uma contagem de clientes de desempenho máximo. Às vezes é 1, ou seja, é melhor com apenas um cliente, mas geralmente é maior. Às vezes, o desempenho diminui novamente acima do limite. Às vezes, apenas atinge um platô.