Vous n'êtes pas identifié(e).
Bonjour,
J’ai un client qui envisage de passer son application d'Oracle à PostgreSQL et il a plusieurs questions :
Pour le support de la charge et des performances :
- Il n’existe pas en intégré dans PostgreSQL un équivalent à MTS (connexion Multi-thread) d’Oracle. Ce qui permet d’avoir du partage de mémoire pour les connexions des utilisateurs lorsqu’il y a beaucoup d’utilisateurs connectés en simultané. J’ai vu qu’il existe les produits comme pgpool, memcached, PgBouncer, …
Peut-on comparer leur fonctionnement à celui de MTS sur Oracle ?
Quel est le meilleur d’entre eux du point de vue installation, utilisation, fiabilité, ... ?
- L'activité transactionnelle de l'application d’origine est élevée: 200 à 300 par secondes. (400000 pages/jour)
La base PostgreSQL peut-elle supporter cela et avec quelle machine ?
Pour info, voici les opérations que le client a du effectuer sur leur base Oracle pour obtenir des performances élevées et linéaires avec 400000 pages/jour de traitement :
- Mise en oeuvre du mode MTS avec 10 shared servers / 25 dispatchers
- Nettoyage des sessions après 15 secondes d'inactivité
- Max connexion: 2000
- 10 GO de swap pour 16 GO de RAM
- Ajout de collecte de statistiques sur les tables les plus volumineuses
Merci par avance pour vos réponses.
Cordialement
Ugo BRUNEL
Hors ligne
Tout d'abord, un joli disclaimer : je ne connais pas grand-chose à Oracle.
Ce qui permet d’avoir du partage de mémoire pour les connexions des utilisateurs
Partage de mémoire pour ? le cache de la base de données ? déjà fait par défaut par PostgreSQL. Autre chose ?
pgpool, memcached, PgBouncer
pgpool a beaucoup de possibilités de fonctionnement mais je suppose que dans votre cas, le but est d'utiliser le pooler de connexions. C'est un outil très utilisé lorsque beaucoup de connexions sont nécessaires. Fréquemment utilisé pour des services web. La partie répartition de charge est intéressante aussi.
pgbouncer ne sert qu'au pooling de connexions. Son intérêt est qu'il ne fait que ça, donc il est très petit, très rapide et très efficace.
- L'activité transactionnelle de l'application d’origine est élevée: 200 à 300 par secondes. (400000 pages/jour)
On parle bien de 200 à 300 transactions par seconde ? si c'est bien ça, ça me paraît peu.
- Max connexion: 2000
PostgreSQL sait bien gérer les connexions mais au delà de 1000, il a besoin d'aide. pgPool ou pgBouncer, au choix.
Guillaume.
Hors ligne
Bonjour Guillaume et merci pour vos réponses.
Sur Oracle, MTS permet de partager la mémoire des connexions lorsqu'il y a beaucoup d’utilisateurs connectés en simultané (Typiquement les services Web).
En effet, sur Oracle en mode dédié (contrairement au mode MTS), chaque session possède son propre espace de mémoire (tri, variables, …), il est donc nécessaire d’avoir suffisamment de mémoire RAM pour gérer toutes les connexions. On met le mode MTS pour partager les connexions et avoir donc un espace mémoire, pour les connexions, limité.
Votre description de pgPool et de pgBouncer a l’air de correspondre à cette fonctionnalité.
Vous dites que 200 à 300 transactions par seconde vous paraissent peu. Pour vous il n’y a pas besoin d’un serveur très puissant ?
Bien sûr, tout dépend du type de transaction.
Le client indique que pratiquement toutes les requêtes sont simples mais longues (unions multiples, group by, …).
Cordialement
Ugo BRUNEL
Hors ligne
Si c'est un service web avec un nombre conséquent d'utilisateurs, j'aurais tendance à mettre pgPool ou pgBouncer. Le choix entre les deux dépend surtout si vous avez besoin de faire de la répartition de charge. Dans ce cas, il vous faudra le couple pgPool/Slony (le premier pour le pooling de connexion et la redirection des requêtes, le second pour la réplication). Dans le cas contraire, vous avez tout intérêt à utiliser pgBouncer.
Il faut savoir qu'au niveau de PostgreSQL la mémoire pour les tris est prise quand le processus en a besoin. Dès qu'il a fini son tri, la mémoire est relachée. Pas de variables dans PostgreSQL même, donc pas de soucis à ce niveau-là.
Mais pour être franc, à moins d'avoir des requêtes sur de très grosses quantités de données pour les tris ou du hachage, il est fort probable que la majorité de la mémoire concernera le cache disque de PostgreSQL.
Quant au nombre de tps, ça dépend évidemment du nombre d'utilisateurs, de la volumétrie, de l'activité. Mais bon, 200/300 tps ne me paraît pas un but inatteignable. SI vous avez de l'argent pour le serveur, utilisez le sur de bons disques et une grosse quantité de mémoire. Le CPU est moins important généralement.
Guillaume.
Hors ligne
Merci pour toutes les informations à vous deux.
Je vais donc expliquer au client qu'il est possible d'atteindre ce nombre de transaction sur une base PostgreSQL.
Le plus compliqué sera de lui dire quel type de serveur il lui faut mais je me baserais sur son serveur actuel.
Il me demande également quels sont les outils d'administration et de supervision sur PostgreSQL.
J'utilise pgadmin 3 depuis longtemps et j'en suis vraiment satisfait pour la partie développement mais je n’en connais pas pour la partie administration et supervision. Ce que j’entends par là, c’est un outil graphique pour voir les requêtes en cours, le top sql, les taux d’utilisation des caches, etc, …
En connaissez et utilisez vous ?
Cordialement
Ugo BRUNEL
Hors ligne
Il n'en existe pas vraiment. Pour les requêtes, le mieux est d'utiliser pgFouine, un petit outil PHP à exécuter sur un log de requêtes qui donnera une idée a posteriori des requêtes lentes. Le taux d'utilisation des caches n'est pas facile à connaître. Le taux de lecture sur disque et en mémoire est beaucoup plus simple mais il faudra exécuter une requête pour cela. Des outils comme munin permettent de récupérer ces informations et de faire de jolis graphiques, notamment avec les plugins munin.
Guillaume.
Hors ligne
Merci Guillaume,
Je suis en train de regarder aussi PGSnap.
Bon je galère pour le tester sur mon poste Windows mais je viens juste de commencer.
Ugo
Hors ligne
Oui, je ne l'ai utilisé qu'une fois sous Windows chez un client et je n'ai pas conservé mes modifs.... honte sur moi, désolé. (si je me souviens bien, je n'ai pas fait beaucoup de modifs)
Guillaume.
Hors ligne
J'ai juste fais qq modifs pour les tests :
- Dans pgsnap.php : j'ai adapté la variable en :
ini_set('include_path', '.;D:/www_php5/pgsnap');- Erreur dans le fichier fichier connect.php :
<b>Warning</b>: fgets(): supplied argument is not a valid stream resource in <b
>D:\www_php5\pgsnap\lib\connect.php</b> on line <b>52</b><br />pour mes tests j'ai juste codé en dur la chaine DSN avec celle qui convient. Ca permet de tester même si c'est pas très pro ;-)
- Je n'ai pas mis les graph en place car j'ai téléchargé Open Flash Chart mais ce n'est pas très clair pour moi dans la doc sur comment mettre en place pour pgsnap. D'ailleur un des fichiers demandés : open_flash_chart_object.php n'est pas présent dans le zip open-flash-chart-2-hyperion.zip. A moins que ce soit un problème de version, j'ai pris la dernière.
En tout cas, il y a pas mal d'informations remontés par l'outil.
Bonne soirée !
Ugo
Hors ligne
Le produit est très intéressant, il montre même les requêtes à exécuter pour récupérer les informations affichées sur chaque page.
Vraiment très pertinent pour apprendre les requêtes d'administration de PostgreSQL.
J'ai bien fait de tester ce produit.
Ugo
Hors ligne
Merci 
Je suis intéressé de connaître les modifications effectuées pour le faire fonctionner sous Windows.
Guillaume.
Hors ligne
Bonjour,
J'utilise xampp avec php 5.
Mon DOCUMENT_ROOT est à D:/www_php5
Modification effectuée rapidement pour tester le module sur ma base PostgreSQL en local :
1. Fichier pgsnap.php :
ligne 23 :
j'ai remplacé :
ini_set('include_path', '.:/usr/share/pgsnap/');par
ini_set('include_path', '.;D:/www_php5/pgsnap');2. Fichier connect.php :
ligne 74:
j'ai ajouté en dur la chaine DSN :
$DSN="host=localhost dbname=webtec user=webtec password=xxxx";Et c'est tout. J'espère que ça pourra vous aider.
Ugo
Hors ligne
OK, merci, je vais regarder ça. J'ai juste un peu peur que ce soit spécifique à ton cas
Guillaume.
Hors ligne