Nombre de connexions max - dizaines de milliers de connexions

Version imprimable

06/04/2017, 14h10
Aizen64

Nombre de connexions max - dizaines de milliers de connexions

Bonjour,

j'ai lu quelques infos sur le sujet et pourtant j'ai bien du mal à trouver une réponse claire à ma question, est-ce potentellement délicat pour un serveur dédié aujourd'hui de gérér des dizaines de milliers d'utilisateurs avec du SELECT ? Prenons un exemple, un site acceulllant 50 000 utilisateurs.

Bien sur, tout dépend des ressources du serveur, j'ai juste tendance à penser que vu la puissance de calcul actuelle, faire ce type d'opération n'est pas si compliqué.

Quelqu'un a des infos claires sur le sujet à partager ?
07/04/2017, 09h49
Arkhena

Bonjour,

"50 000 utilisateurs qui font du SELECT", ça ne veut malheureusement pas dire grand chose (même si je suis bien consciente que vous avez galéré pour obtenir ne serait-ce que cette information).
Ce qui est important, c'est
- le nombre d'utilisateurs simultanés (en moyenne et en pointe)
- le temps de réponse moyen des SELECT effectués
- s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues
- le dimensionnement de la machine (ou des machines en cas de load balancing sur des Hot Standbys)

En gros, le nombre de connexions simultanées maximum est lié au paramètre max_connections (https://www.postgresql.org/docs/9.6/...onnection.html) qu'on peut setter différemment en fonction du matériel qu'on a.

Cordialement,

Arkhena
07/04/2017, 10h04
SQLpro

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.

Les gros SGBDR commerciaux supportent en pratique plusieurs dizaines de milliers de connexions simultanées, car il utilisent un pooler interne mais il faut que le serveur soit bien dimensionné. Par exemple sur le serveur d'Eurydile (registre du commerce) nous avions des pointes à plus de 30 000 connexions simultanées sur un serveur à 64 cœurs hyperthreadé (donc 128 vcore). Mais c'est du MS SQL Server !

A +
07/04/2017, 13h25
alassanediakite

Citation:

Envoyé par SQLpro

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool...

Encore de la désinformation gratuite. Et encore une confirmation de ce que vaut l'homme et de ce qu'il dit.
07/04/2017, 13h38
NULL008

@sqlpro vous été payé de microsoft pour faire ces types de publicités ?
07/04/2017, 14h16
Arkhena

Citation:

Envoyé par SQLpro

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.

Bonjour SQLPro,

Je ne demande qu'à vous croire, mais je suis comme Saint Thomas... Pouvez-vous m'expliquer ce qui vous fait penser cela ?

Cordialement,

Arkhena
09/04/2017, 19h06
SQLpro

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

A +
09/04/2017, 22h52
gorgonite

Citation:

Envoyé par SQLpro

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Donc "le bon coin" perdrait volontairement plusieurs milliers d'euros par an en infrastructure juste pour éviter un SGBDR commercial... tout en restant gratuit pour pas mal de particuliers. Sont-ils subventionnés par de généreux mécènes anti-SQL server ?
Est-ce vraiment la seule raison ? Ont-ils une autre contrainte qui ne serait pas supportée par un seul serveur avec SGBDR commercial ?

Cela semble assez peu plausible, pour des raisons purement idéologiques, non ?
09/04/2017, 23h43
alassanediakite

Citation:

Envoyé par SQLpro

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

A +

Faisons l'inverse...
Donne-nous l'aveu officiel de "le bon coin" sur ce choix, on fera le mea-culpa.
@+
10/04/2017, 09h27
Arkhena

Bonjour,

Je suis désolée SQL-Pro, je crois qu'on s'est mal compris... Je voulais une preuve, non un exemple...

Cordialement,

Arkhena
10/04/2017, 15h22
SQLpro

J'aime beaucoup la bêtise de certains...

Citation:

Envoyé par Arkhena

Je suis désolée SQL-Pro, je crois qu'on s'est mal compris... Je voulais une preuve, non un exemple...

Il n'est pas possible de donner une preuve négative. Même en justice... En effet prouver la non existence nécessiterait d'arrêter tous les projets de la terre, en faire un exemple exhaustif et constater que cela n'existe pas. C 'est pourquoi je vous ais montré le preuve du contraire !

Croyez vous que ce soit pas masochisme que le bon coin utilise plus de 120 serveur PG ? Non, c'est tout simplement que la "scalability" verticale de PG est très mauvaise. Ceci est d'ailleurs confirmé par les développeurs du noyau PG eux même dans cet article :
https://wiki.postgresql.org/wiki/Sim...pment_Projects
En particulier le processus VACUUM... ou il est dit que :
VACUUMs are clearly a problem for VLDBs,

A +
10/04/2017, 17h39
alassanediakite

"Science sans honnêteté n'est que ruine de l'âme"

Citation:

Envoyé par SQLpro

Il n'est pas possible de donner une preuve négative.

pour autant on ne peut pas compter le nombre de fois que tu as surmonté cette impossibilité.

Citation:

Envoyé par SQLpro

Croyez vous que ce soit pas masochisme que le bon coin utilise plus de 120 serveur PG ? Non, c'est tout simplement que la "scalability" verticale de PG est très mauvaise.

des allégations sans fondement et qui n'ont rien a avoir avec "nombre max de connections"

Citation:

Envoyé par SQLpro

Ceci est d'ailleurs confirmé par les développeurs du noyau PG eux même

FAUX,

Citation:

This page contains details of a number of development projects that I'm either working on or planning to work on in the next Development Cycle.
Well, it did once. This was last updated in about 2010.

Sont les propos d'un individu et n'engage que lui. Par ailleurs, vous voulez nous faire consommer un avis de 2010!!!

Citation:

Envoyé par SQLpro

VACUUMs are clearly a problem for VLDBs,

La récupération des espaces morts est inhérente à tous les SGBDR. C'est un choix judicieux mais qui à ces inconvénients surtout avec les grosses bases de données (VLDB).
Amène quelque chose de plus honnête...
@+
10/04/2017, 19h56
SQLpro
Citation:

Envoyé par alassanediakite

La récupération des espaces morts est inhérente à tous les SGBDR. C'est un choix judicieux mais qui à ces inconvénients surtout avec les grosses bases de données (VLDB).
Amène quelque chose de plus honnête...@+

Tout à fait, mais cela est minimal dans SQL Server par exemple car :
- soit il n'y a pas de versionnement des lignes (verrouillage pessimiste) donc aucun espace mort lié aux copies des lignes
- soit en mode snapshot (verrouillage optimiste) la version des lignes est gérée dans la tempdb, donc pas dans les bases de production...
Cela n'est donc ni pénalisant ni bloquant au contraire du VACUUM de PG.

En sus la récupération des espaces mort peu se faire en mode ON LINE, sans blocage...
- ALTER TABLE ma_table REBUILD WITH ( ONLINE = ON )
- ALTER INDEX mon_index ON ma_table WITH ( ONLINE = ON )
Ce qui n'est pas le cas dans PG...

A +
15/04/2017, 01h30
Aizen64

OK, merci pour vos réponse.

Je n'ai jamais eu à considérer ces questions de performance auparavant d'où mes questions, quelques infos supplémentaires :
- en moyenne :
=> nombre de lignes retournées par requête : 30.
=> nombreuses jointures comme BDD complexe.
=> temps de réponse d'une requête HTTP lors d'un allez retour au SGBD, les 2 étant sur un serveur différent : 500 ms.
=> temps d'INSERT/UPDATE via WS : en localhost : > 1 seconde, ce qui me parait énorme alors que je n'ai que 2 ou 3 connexions actives. Les perfs sont équivalentes en prod.

Le reste de mon argumentaire mais je le pose quand même, l'ignorance n'est pas un crime, alors autant se cultiver.
Le SQL a été mis en place dans les années 70, le principe est justement de mutualiser l'information et la rendre disponible à différents client, par exemple, de nombreux sites gèrent des dizaines de milliers d'utilisateurs. Les CPU serveur aujourd'hui ont une puissance colossale, idem pour la quantité de RAM, comment peut on expliquer par exemple qu'un CPU serveur avec plus de 10Go de RAM puisse uniquement gérer quelques centaines de connexions ?

Des explications et articles sont les bienvenus.
18/04/2017, 20h19
SQLpro
Citation:

Envoyé par Aizen64

OK, merci pour vos réponse.

Je n'ai jamais eu à considérer ces questions de performance auparavant d'où mes questions, quelques infos supplémentaires :
- en moyenne :
=> nombre de lignes retournées par requête : 30.

Très faible

Citation:

=> nombreuses jointures comme BDD complexe.

PostGreSQL n'est pas le plus à l'aise en cette matière. À défaut il sait optmiser à peut près bien une requête pourvue de 12 jointures simples (ne portant que sur col1 = col2) mais on peut le régler à plus au détriment du temps. Au dela son algorithme "geqo" censé réduire le temps de calcul du plan de requête provoque des plans parfois catastrophiques... https://postgresql.developpez.com/do....3.0/geqo.html Rien à voir avec les optimiseurs des gros SGBDR comme Oracle ou mieux encore SQL Server qui savent traiter efficacement des dizaines, voire des centaines de jointures en un temps record...

Citation:

=> temps de réponse d'une requête HTTP lors d'un allez retour au SGBD, les 2 étant sur un serveur différent : 500 ms.

ça ne veut rien dire, il faudrait diagnostiquer les différents temps, et en cette matière PG ne dispose d'aucun outil au contraire par exemple de SQL Server ou, sur une requête, on peut savoir à quel endroit on perd du temps : disque, RAM, réseau, CPU, attente de verrouillage, de méta données, de claul de plan de gestion du cache, etc... https://www.brentozar.com/sql/wait-stats/

Citation:

=> temps d'INSERT/UPDATE via WS : en localhost : > 1 seconde, ce qui me parait énorme alors que je n'ai que 2 ou 3 connexions actives. Les perfs sont équivalentes en prod.

Cela dépend de la journalisation, mais PostrGreSQL n'utilise qu'un seul journal de transaction pour toutes les bases d'un cluster là ou SQL Server utilise un journal par base, voire plus (un journal distinct pour les tables temporaires). Là encore le manque d'outil de PG le redn difficile à diagnostiquer...

Citation:

Le reste de mon argumentaire mais je le pose quand même, l'ignorance n'est pas un crime, alors autant se cultiver.
Le SQL a été mis en place dans les années 70,

Non, vous confondez 3 choses :
- l'algèbre relationnelle qui date effectivement de 1970, le papier fondateur de Franck Edgar Codd étant visible à l'URL : http://users.dcc.uchile.cl/~cgutierr...Data_Banks.pdf
- la réalisation en pratique des premiers SGBDR : Ingres (de l'université de Berkeley 1979), Oracle de Relational Software (1979) et System-R d'IBM (1980). https://www.guug.de/lokal/muenchen/2...-14/rdbmsc.pdf
- le langage SQL qui démarre en 1974 sous le nom de SEQUEL, puis est normalisé en 1986 par l'ANSI et 1987 par l'ISO. http://www.almaden.ibm.com/cs/people...equel-1974.pdf
Citation:

le principe est justement de mutualiser l'information et la rendre disponible à différents client, par exemple, de nombreux sites gèrent des dizaines de milliers d'utilisateurs. Les CPU serveur aujourd'hui ont une puissance colossale, idem pour la quantité de RAM, comment peut on expliquer par exemple qu'un CPU serveur avec plus de 10Go de RAM puisse uniquement gérer quelques centaines de connexions ?

Un SGBDR est par nature très consommateurs de ressources de toutes nature :
1) RAM pour la mise en cache des données, des métadonnées des plans de requêtes et du code interprété... les connexions consommant chacune de la mémoire....
2) DISQUE pour le stockage des données et la journalisation des transactions
3) CPU pour le calculs des plans de requêtes, la gestion du cache, les algorithmes de parcours de données et de calculs (jointures, agrégats...)
Le problème est de distinguer d'un côté, les connexions au serveur, qui peuvent être "dormantes" et sont toujours en nombre limitées et pour les gros SGBDR (Oracle : 2 048, SQL Server : 32 767) gérés par pool, et d'un autre côté les requêtes exécutées simultanément. En standard PG n'ayant pas de mécanises de pooling, cela dépend du hardware, mais rares sont les installations supportant en pratique plusieurs centaines de connexions. https://wiki.postgresql.org/wiki/Num...se_Connections
Pour obtenir d'excellentes performances, les gros SGBDR (Oracle, DB2, SQL Server) dispose d'un OS interne qui gère les threads, la RAM et les accès disque (ils ne passant pas par l'OS hôte, mais accède directement aux disques/SAN par des routines de bas niveau). Par exemple dans SQL Server l'OS interne est appelé SOS (cela ne s'invente pas !!! ;-)

Citation:

Des explications et articles sont les bienvenus.

Aujourd'hui dans ma clientèle, un serveur moyen s'installe avec 256 Go de RAM et 24 à 32 cpu et pour le stockage, en général, il dépasse le TO d'emblée.
Personnellement j'ai du revoir mes outils interne il y a 18 mois (je fais beaucoup d'audit de bases SQL Server) et donc mon PC de dev est un HP Z840 avec 2 CPU XEON 12 cœurs multithreadés (donc 48 cœurs logiques), 128 Go de RAM (que je dois porter à 256 dans les semaines qui viennent), 8 disques SAS en RAID 10 pour un stockage de 4 To, 2 dsques SSD de 1 To en RAID 1 sur port PCI, et deux NAS en réseau escsi de 24 To (QNAP).

A +
20/04/2017, 17h11
Aizen64

Si on revient une dizaine d'années en arrière, allez au début des années 2000, comment les gros sites géraient leurs traffic ? Des centaines d'instance de SGBD répliqués ?
20/04/2017, 20h21
SQLpro
Citation:

Envoyé par Aizen64

Si on revient une dizaine d'années en arrière, allez au début des années 2000, comment les gros sites géraient leurs traffic ? Des centaines d'instance de SGBD répliqués ?

Pour info le plus gros site web marchand français était la fnac et à démarré avec 4 serveurs MS SQL Server 2000 en parallèle; Aujourd'hui il y en as 8. Le problème du "scale out" c'est qu'il faut répliquer une bonne partie des donné&es de la base ce qui est très couteux. On essaye de faire l'inverse au départ : "scale up", c'est à dire partir sur des gros serveurs sui ont beaucoup de RAM de disques et de CPU.

Le pooling sert à faire patienter les connexions et donc les déconnecter en les mettant en réserve, dès qu'il n'y a plus de raison de maintenir une connexion chaude.

Par exemple le dernier gros serveur que j'ai installé pour un opérateur télécom mobile avait 1 To de RAM, 128 cpu et 80 To de disques composé de la sorte :
- 2 cartes fusion IO de 2 To (en RAID 1) sur port PCI (soit 2 To)
- 16 disques SSD interne de 1 To en RAID 1 (soit 8 To)
- baie SAN dédiée de 64 disques SAS de 1,2 To à 10 krpm en RAID 10 (soit 38 To)
- seconde baie SAN dédiée de 32 disques SATA de 8 To en RAID 1 (soit 128 To)
Ceci afin d'assumer la volumétrie des données et des sauvegardes avec du stockage qui va du très chaud (SSD) au tiède (SATA).

A +
21/04/2017, 10h43
skuatamad

Citation:

Envoyé par Arkhena

- s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues

Non, les SELECT ne sont pas bloqués par les écritures concurrentes.

Table-level Lock Modes

Citation:

ACCESS EXCLUSIVE

Conflicts with locks of all modes (ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE). This mode guarantees that the holder is the only transaction accessing the table in any way.

Acquired by the ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, and VACUUM FULL commands. This is also the default lock mode for LOCK TABLE statements that do not specify a mode explicitly.

Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.
21/04/2017, 20h09
SQLpro
Citation:

Envoyé par skuatamad

Non, les SELECT ne sont pas bloqués par les écritures concurrentes.

Tout dépend du mode de verrouillage...
Par défaut dans PostGreSQL, le mode de verrouillage est le mode optimiste qui se traduit par un versionnement de lignes et donc ne bloque pas les écritures, sauf dans le cas de la lecture des métadonnées.

Dans certaines bases, c'est le mode pessimiste par défaut (Access, Sybase, MS SQL Server). Donc une lecture bloque les écritures.

Certaines bases permettent les deux, il suffit de les paramétrer correctement. C'est le cas de SQL Server.

Mode optimiste...
- Avantage : pas de blocage des écritures par les lectures
- Inconvénient : perte possible de mise à jour, volumétrie accrue due à la génération des versions de ligne, augmentation de la durée des traitements du fait de la génération des copies pour les versions
Mode pessimiste...
- Avantage : une fois engagée, la mise à jour sera effectuée, durée transactionnelle moindre, volumétrie stable
- Inconvénient : blocage des écritures par les lectures
Le mieux étant évidemment de pouvoir jouer sur les deux, ce que PG ne sait pas faire.... Et la gestion des copies de lignes est assez mal faite dans PG (VACUUM...)

A +