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 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 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 )
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 )
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 )
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.
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.
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.
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%).
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%).
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%).
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.
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.
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.
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
Juste une question : est-ce que deux requêtes peuvent arriver
simultanément ?
JKB
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.
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.
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,
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 :
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 :
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 :
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.
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.
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,
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,
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,
