PostgreSQL - Si j'exécute plusieurs requêtes simultanément, dans quelles circonstances verrais-je une accélération? Dans quelles circonstances verrais-je un ralentissement?

Je vous aborde tous humblement comme quelqu'un qui n'est PAS un DBA, et je suis sûr que ma question est lourde de lacunes conceptuelles et "cela dépend" des mines terrestres. Je suis également à peu près sûr que tous ceux qui choisissent de répondre vont vouloir beaucoup plus de détails que je ne peux en fournir actuellement.

Cela dit, je suis curieux du scénario suivant en général:

• Disons que j'ai deux requêtes non triviales.
• La requête 1 nécessite en moyenne 2 minutes.
• La requête 2 nécessite en moyenne 5 minutes.

Si je les exécute en série, l'une après l'autre, je m'attends à ce que cela prenne 7 minutes en moyenne. Est-ce raisonnable?

Plus que cela, cependant, que se passe-t-il si j'exécute les deux requêtes simultanément? Deux connexions distinctes en même temps.

• Dans quelles conditions puis-je m'attendre à voir une accélération? (Temps total <7 minutes)
• Dans quelles conditions puis-je m'attendre à un ralentissement? (Temps total> 7 minutes)

Maintenant, si j'avais 1000 requêtes non triviales en cours d'exécution simultanément, j'ai le pressentiment que cela entraînerait un ralentissement global. Dans ce cas, où serait probablement le goulot d'étranglement? Processeur? RAM? Disques?

Encore une fois, je sais qu'il est probablement impossible de répondre précisément à la question sans connaître les détails (que je n'ai pas.) Je cherche des lignes directrices générales auxquelles réfléchir lorsque je pose les questions suivantes:

• Dans quelles circonstances les requêtes simultanées entraînent-elles une accélération globale?
• Dans quelles circonstances les requêtes simultanées entraînent-elles un ralentissement global?

Si je les exécute en série, l'une après l'autre, je m'attends à ce que cela prenne 7 minutes en moyenne. Est-ce raisonnable?

S'ils utilisent des ensembles de données non liés, alors oui.

S'ils partagent un ensemble de données et que le cache est froid pour la première requête et que la requête est principalement liée aux E / S, la seconde peut se terminer en quelques instants. Vous devez prendre en compte les effets de mise en cache lors de l'analyse des performances et du timing des requêtes.

Plus que cela, cependant, que se passe-t-il si j'exécute les deux requêtes simultanément? Deux connexions distinctes en même temps.

"Ça dépend".

S'ils utilisaient tous les deux des analyses séquentielles de la même table, alors dans PostgreSQL, ce serait une énorme amélioration des performances en raison de sa prise en charge des analyses séquentielles synchronisées.

S'ils partageaient les mêmes index, ils bénéficieraient probablement des lectures des uns et des autres dans le cache.

S'ils sont indépendants et touchent des données différentes, ils pourraient rivaliser pour la bande passante d'E / S, auquel cas ils pourraient prendre le même temps que l'exécution séquentielle. Si le sous-système d'E / S bénéficie de la concurrence (débit net supérieur avec plus de clients), le temps total peut être inférieur. Si le sous-système d'E / S gère mal la concurrence, cela peut prendre plus de temps que leur exécution séquentielle. Ou ils peuvent ne pas être du tout liés aux E / S, auquel cas s'il y a un processeur libre pour chacun, ils pourraient bien s'exécuter comme si l'autre ne fonctionnait pas du tout.

Cela dépend beaucoup de la configuration matérielle et système, de l'ensemble de données et des requêtes elles-mêmes.

Maintenant, si j'avais 1000 requêtes non triviales en cours d'exécution simultanément, j'ai le pressentiment que cela entraînerait un ralentissement global. Dans ce cas, où serait probablement le goulot d'étranglement? Processeur? RAM? Disques?

Oui, cela ralentirait très probablement les choses pour un certain nombre de raisons.

• Propres frais généraux dans la coordination inter-processus, gestion des transactions et de verrouillage de PostgreSQL, la gestion tampon, etc. Cela peut être tout à fait un grand coût, et PostgreSQL ne sont pas vraiment conçus pour les comptes clients de haut - il fonctionne mieux si vous file d' attente de travail .

• Concurrence pour la mémoire de travail, le cache, etc.

• Les frais généraux de planification du système d'exploitation car il jongle avec 1000 processus concurrents, tous manquant de tranches horaires Assez mineurs ces jours-ci, les systèmes d'exploitation modernes ont des planificateurs rapides.

• Thrashing d'E / S. La plupart des systèmes d'E / S ont un nombre de clients de performances maximales. Parfois, c'est 1, c'est-à-dire qu'il vaut mieux avec un seul client, mais c'est souvent plus. Parfois, les performances diminuent à nouveau au-dessus du seuil. Parfois, il atteint juste un plateau.