Est ce que postgresql est plus performant que mysql avec un seul user ?
Le
Jerome PAULIN
Bonjour,
Je vous fait part de ma problématique :
- je dispose actuellement d'une base comportant quelques tables (1
million de lignes pour la plus remplie, aux alentour de 50000
enregistrements pour les autres)
- je dispose d'un ensemble de fonctions de calcul (environ 20 fonctions)
que j'utilise abondamment. Ces fonctions correspondent contiennent
souvent une ou plusieurs requêtes pour fournir les données de calcul).
- la machine est un dual-core avec 8 Go de RAM, sous Centos 5.3
- je n'ai qu'un seul utilisateur simultané sur la base
- mes requêtes sont de la forme :
select
champ1
champ2,
champ3,
calcul1(champ1),
calcul2(champ2),
calcul3(champ1),
calcul4(champ3)
from
table1
inner join table2 using(lien)
inner join table3 using(lien)
where
champA=valeurA
and champB between valeurMini and ValeurMaxi
Lorsque je lance ma requête, j'ai des temps de réponse très(trop) longs.
Je constate que toutes les requêtes des fonctions de calcul sont
exécutées sur un seul cœur.
Existe t il un moyen de forcer MySQL à utiliser toutes les ressources
CPU disponibles ?
Y a t il un intérêt à basculer sous postgreSQL pour améliorer les temps
de réponse ?
Merci d'avance pour vos idées et suggestions.
Cordialement,
gg
Je vous fait part de ma problématique :
- je dispose actuellement d'une base comportant quelques tables (1
million de lignes pour la plus remplie, aux alentour de 50000
enregistrements pour les autres)
- je dispose d'un ensemble de fonctions de calcul (environ 20 fonctions)
que j'utilise abondamment. Ces fonctions correspondent contiennent
souvent une ou plusieurs requêtes pour fournir les données de calcul).
- la machine est un dual-core avec 8 Go de RAM, sous Centos 5.3
- je n'ai qu'un seul utilisateur simultané sur la base
- mes requêtes sont de la forme :
select
champ1
champ2,
champ3,
calcul1(champ1),
calcul2(champ2),
calcul3(champ1),
calcul4(champ3)
from
table1
inner join table2 using(lien)
inner join table3 using(lien)
where
champA=valeurA
and champB between valeurMini and ValeurMaxi
Lorsque je lance ma requête, j'ai des temps de réponse très(trop) longs.
Je constate que toutes les requêtes des fonctions de calcul sont
exécutées sur un seul cœur.
Existe t il un moyen de forcer MySQL à utiliser toutes les ressources
CPU disponibles ?
Y a t il un intérêt à basculer sous postgreSQL pour améliorer les temps
de réponse ?
Merci d'avance pour vos idées et suggestions.
Cordialement,
gg
Bonjour,
Je ne pense pas que MySQL sache utiliser plusieurs cores pour une
requête, et PostgreSQL, je suis sûr que non.
Mais il faudrait peut-être commencer par voir s'il ne manque pas des
index, et si le parametrage de la base est correctement fait.
Ensuite, s'il y a plusieurs requetes, il suffit de les lancer en
parallèle, chacune dans leur session, et là, je pense pouvoir avancer
que PostgreSQL s'en sort mieux.
Enfin, mais le volume de données indique ne le justifie pas, il est
existe des outils spécialisés pour traiter de grosses requetes
analytiques, tel que Greenplum ( basé sur PostgreSQL )
--
Sébastien
Hé bien concernant les index, je suis a peu près sûr de mon coup, c'est
vraiment un problème de charge que je rencontre (et très spécifique, car
un seul user sur la base).
Lorsque j'observe ce qui se passe au niveau du serveur (via
mysqladministrator), je vois bien une montée d'activité correspondant
aux requetes des fonctions (entre 500 et 1000 requetes/seconde, ce que
je trouve tout a fait bien vu les caractéristiques du serveur), mais
seul un coeur se trouve chargé (à 100%).
Comme tu le dis, le volume de données n'est pas important.
PostgreSQL ne proposant pas la fonctionnalité que je recherche, il me
reste 2 alternatives : soit modifier mon application pour que les
calculs soient effectués en parallèle, soit passer à Oracle qui permet
le fonctionnement que je recherche (mais je ne connais pas suffisamment
Oracle pour le mettre en place rapidement sur mon serveur).
Merci de ton aide
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Si tu as plusieurs requêtes à faire tourner simultanément, PostgreSQL
utilisera tous les processeurs, ce qu'il ne sait pas faire pour une
seule requête.
--
Jean-Max Reymond
CKR Solutions Open Source http://www.ckr-solutions.com
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jean-Max Reymond ?crivait dans fr.comp.applications.sgbd :
Mysql aussi, mais Mysql étant un goret, il va commencer par bouffer
toute la RAM puis du swap pou faire ses requêtes en parallèle.
L'intérêt de Postgres, c'est une utilisation bien plus rationnelle
des ressources.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Non, j'exécute ma requête depuis HeidiSQL, donc une seule requête à la
fois (et, je le rappelle, un seul utilisateur), mais qui appelle
plusieurs fonctions de calcul pour chaque enregistrement. Et, bien
entendu, ce que je cherche à faire, c'est d'exploiter au mieux la
puissance CPU du serveur pendant ces calculs.
gg
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Le fait de n'avoir qu'un seul utilisateur ne signifie pas qu'il
n'effectue qu'une seule requête à un instant t.
Personnellement, je commencerais par regarder s'il n'était pas
possible de lancer _deux_ requêtes simultanées plutôt que de faire
une usine à gaz avec des requêtes multithreadées.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Ah mon avis le problème vient plutot des IO.
Disque dur trop lent.
Alors la plusieurs solution.
- Tu change les disques durs pour mettre des 15.000 tours
- Tu met suffisamment de RAM pour que la plupart des accès soit cachée.
- T'installe deux SSD en RAID
Reste aussi effectivement l'index a envisager si ce n'est pas deja le cas.
Bref. comme il n'y a pas de calcul dans ta requete c'est sans doute pas
le CPU qui pose problème.
Etienne
bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
--
Sébastien
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.