Est ce que postgresql est plus performant que mysql avec un seul user ?
20 réponses
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 ?
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 ?
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
Le 08/04/2010 11:20, Jerome PAULIN a écrit :
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 ?
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 )
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 ?
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
Jerome PAULIN
Sebastien Lardiere a écrit :
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 )
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
Sebastien Lardiere a écrit :
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 )
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).
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 )
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
JKB
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Sebastien Lardiere a écrit :
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 )
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.
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.
Le 08-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Sebastien Lardiere a écrit :
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 )
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.
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.
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Sebastien Lardiere a écrit :
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 )
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.
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.
Jean-Max Reymond
Le 08/04/2010 14:23, Jerome PAULIN a écrit :
Sebastien Lardiere a écrit :
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 )
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%).
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
Le 08/04/2010 14:23, Jerome PAULIN a écrit :
Sebastien Lardiere a écrit :
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 )
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%).
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
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 )
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%).
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
JKB
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jean-Max Reymond ?crivait dans fr.comp.applications.sgbd :
Le 08/04/2010 14:23, Jerome PAULIN a écrit :
Sebastien Lardiere a écrit :
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 )
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%).
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.
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.
Le 08-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jean-Max Reymond ?crivait dans fr.comp.applications.sgbd :
Le 08/04/2010 14:23, Jerome PAULIN a écrit :
Sebastien Lardiere a écrit :
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 )
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%).
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.
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.
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jean-Max Reymond ?crivait dans fr.comp.applications.sgbd :
Le 08/04/2010 14:23, Jerome PAULIN a écrit :
Sebastien Lardiere a écrit :
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 )
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%).
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.
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.
Jerome PAULIN
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
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.
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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
JKB
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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
Le fait de n'avoir qu'un seul utilisateur ne signifie pas qu'il n'effectue qu'une seule requête à un instant t.
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.
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.
Le 08-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
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
Le fait de n'avoir qu'un seul utilisateur ne signifie pas qu'il
n'effectue qu'une seule requête à un instant t.
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.
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.
Le 08-04-2010, ? propos de Re: Est ce que postgresql est plus performant que mysql avec un seul user ?, Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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
Le fait de n'avoir qu'un seul utilisateur ne signifie pas qu'il n'effectue qu'une seule requête à un instant t.
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.
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.
WebShaker
Le 08/04/2010 11:20, Jerome PAULIN a écrit :
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 :
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
Le 08/04/2010 11:20, Jerome PAULIN a écrit :
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 :
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.
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 :
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
Sebastien Lardiere
Le 08/04/2010 14:51, Jerome PAULIN a écrit :
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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.
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
Le 08/04/2010 14:51, Jerome PAULIN a écrit :
JKB a écrit :
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
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.
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 ?
Juste une question : est-ce que deux requêtes peuvent arriver simultanément ?
JKB
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.
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
Jerome PAULIN
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :
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,
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.
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :
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,
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.
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,
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.