PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Connexions simultannées

Technique - général | Connexions simultannées

Par ducteil le 31/08/2008 - 03:15

Bonjour

Nous avons des bases de données de petites tailles (la somme < 4 Go), qui sont utilisées pour synchroniser 120 autres bases : nous travaillons essentiellement en mode déconnecté.

Depuis peu, quelques tables sont accessibles en mode connecté, et le nombre maximum de connexions simultanées ne cessent d'être atteint. Notre max_connections est à 150.

Questions
Quelle configuration (Ram, proc) dois-je prévoir pour la mise en place d'un serveur avec un max_connections à 500, tout en ayant un OS stable (on voudrait rester sous RedHat), et une performance acceptable ?
Comment dois-je configurer les paramètres du noyau linux ?

La vitesse et l'architecture(RAID) des disques sont elle un gage d'efficacité pour de si petites bases?

Je crois qu'il y a que sur ce site que je pourrai avoir un avis éclairé.
Merci d'avance.

Cordialement
Olivier

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Pool de connexions

SAS/ = 12 Septembre, 2008 - 19:02

Bonjour,

Peut-ĂŞtre devriez-vous envisager un pool de connexions avant de modifier l'architecture pour atteindre 500 cnx.

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr


Pool de connexions

ducteil/ = 16 Septembre, 2008 - 02:36

Bonjour,

J'avais déjà essayé pg-pool sur un serveur moins performant et avais remarqué des ralentissements, et même un blocage du service(et nous n’étions qu’une centaine).
Une augmentation de la ram, et quelques modifications de paramètres nous ont permis d’avoir un système stable. Mais je veux anticiper la charge de 500 users parallèles.

Comment faire pour tester pgpool ou PgBouncer en situation réelle ?
En supposant que ma trésorerie soit sans fin, faudrait-il mieux s'orienter vers une solution logiciel de "pool de connexions", ou une amélioration matériel du serveur (DD, ram, OS, noyau, etc.).

Je ne suis malheureusement pas le seul dans ce cas et nous sommes incapables d’avoir une vision claire sur ce problème.
Même de simples idées seraient appréciées.

Merci d’avance.

Cordialement
Olivier


Risques

SAS/ = 20 Septembre, 2008 - 05:57

Bonjour,

Il faut bien comprendre qu'un concentrateur de connexion comme pgpool va agir en ouvrant un nombre prédéfini et limité de connexions au serveur.
Ces connexions sont persistantes. Si dans votre code vous maintenez des connexions persistantes, alors vous allez vite bloquer le serveur, plus vite encore que sans concentrateur.

J'ai pour ma part déjà mis pgpool en place sur des architectures Web accueillant plusieurs milliers d'utilisateurs en simultané avec un réel gain.

Il me semble donc, que même si votre trésorerie était illimité, vous ne pourriez vous passer d'un pool de connexions. Qu'il soit géré par pgpool, pgbouncer ou même par Tomcat...

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr


Clients Lourds

ducteil/ = 20 Septembre, 2008 - 16:37

Bonjour

Vos réponses ont vraiment éclairé ma lanterne.

Nous gérons des sites sécurisés où nous avons des milliers de clients que se connectent sur une base analogue ; nous n’avons jamais rencontré de problèmes de perte puissance ou de gains, les requêtes relativement lourdes sont dans des transactions : nous n’avons pas eu à utiliser pas de connexions permanentes (PHP is magic !).
Par contre, nous sommes, dans le cas qui m’intéresse, dans un système de clients lourds pour notre application métier, et voudrions faire le meilleur choix pour notre prochain serveur SQL.
Le plus agaçant dans cette histoire est que
+ les sessions de connexions sont relativement courtes : la réplication dure moins d’une minute
+ nous sommes sur une base de moins de 4 Go (8 avec les indexes)
+ mais nous pouvons dépasser 150 connexions simultanées.

Si l’on part comme principe, qu’il nous faille un pool de connexion, et que nous voudrions être prêt pour les 500 connexions simultanées, sur quelles ressources (CPU, RAM, OS) devrais-je porter toute mon attention ?

Merci d’avance !

Cordialement
Olivier


Pas grand-chose :-)

SAS/ = 23 Septembre, 2008 - 12:13

Bonjour,

Dans un premier temps, vu ce que vous nous dites (cnx rapides, nombreuses, petite volumétrie), je dirais que vous pourriez faire un test sans investir.

Si effectivement vous rencontrez des difficultés dans ce cas, il pourra devenir intéressant de s'intéresser à la RAM, puis à étendre horizontalement votre architecture (rajout de serveurs...).

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr


© PostgreSQLFr, tous droits rĂ©servĂ©s.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.