lenteur qt-mysql

Le
G.Delafond
Bonjour

J'utilise un programme en Qt sur Mandriva avec base de données mysql. Tout
se passe très bien, en local comme en réseau.

Le problème, c'est que j'ai besoin de migrer la base sur un serveur Debian,
et que les performances sont effondrées (divisées par 15 environ).
Les données arrivent au compte-gouttes, alors que le réseau est libre et que
la charge processeur est nulle.

J'ai fait des tests en créant à la volée une interface minimaliste avec
qt-designer, et c'est hyper lent dès qu'il y a un petit peu de données à
lire.

En revanche, avec PHP, c'est un avion.

Je ne sais pas trop où chercher.

Une idée ?

--
G.Delafond
http://www.delafond.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #21897791
Le 21-04-2008, à propos de
lenteur qt-mysql,
G.Delafond écrivait dans fr.comp.applications.sgbd :
Bonjour



Bonjour,

J'utilise un programme en Qt sur Mandriva avec base de données mysql. Tout
se passe très bien, en local comme en réseau.

Le problème, c'est que j'ai besoin de migrer la base sur un serveur Debian,
et que les performances sont effondrées (divisées par 15 environ).
Les données arrivent au compte-gouttes, alors que le réseau est libre et que
la charge processeur est nulle.

J'ai fait des tests en créant à la volée une interface minimaliste avec
qt-designer, et c'est hyper lent dès qu'il y a un petit peu de données à
lire.

En revanche, avec PHP, c'est un avion.

Je ne sais pas trop où chercher.



Il serait bon de savoir comment le bazar mysql est configuré (par
exemple en donnant le fichier my.cnf). Mysql est une saleté à
configurer et à optimiser (je me demande si les verbes ne sont pas
en trop ici ;-) ). Par ailleurs, quel est le moteur de base ?
myisam, innodb, autre ?

En changeant l'un ou l'autre des paramètres, on arrive à changer le
comportement de mysql du tout au tout.

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.
steph
Le #21897781
JKB a écrit :

Il serait bon de savoir comment le bazar mysql est configuré (par
exemple en donnant le fichier my.cnf). Mysql est une saleté à
configurer et à optimiser (je me demande si les verbes ne sont pas
en trop ici ;-) ). Par ailleurs, quel est le moteur de base ?
myisam, innodb, autre ?



il y a des outils comme tuning-primer.sh
G.Delafond
Le #21897771
JKB wrote:

Il serait bon de savoir comment le bazar mysql est configuré (par
exemple en donnant le fichier my.cnf). Mysql est une saleté à
configurer et à optimiser (je me demande si les verbes ne sont pas
en trop ici ;-) ). Par ailleurs, quel est le moteur de base ?
myisam, innodb, autre ?

En changeant l'un ou l'autre des paramètres, on arrive à changer le
comportement de mysql du tout au tout.

JKB



my.cnf
#
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently
parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#On peut peut-être jouer sur la taille des caches ou buffers ?
#La RAM est de 1 Go

log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See
README.Debian!
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 64M

[mysql]

[isamchk]
key_buffer = 16M

!includedir /etc/mysql/conf.d/


--
G.Delafond
http://www.delafond.org
JKB
Le #21897761
Le 21-04-2008, à propos de
Re: lenteur qt-mysql,
G.Delafond écrivait dans fr.comp.applications.sgbd :
JKB wrote:

Il serait bon de savoir comment le bazar mysql est configuré (par
exemple en donnant le fichier my.cnf). Mysql est une saleté à
configurer et à optimiser (je me demande si les verbes ne sont pas
en trop ici ;-) ). Par ailleurs, quel est le moteur de base ?
myisam, innodb, autre ?

En changeant l'un ou l'autre des paramètres, on arrive à changer le
comportement de mysql du tout au tout.

JKB



my.cnf
#
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently
parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#On peut peut-être jouer sur la taille des caches ou buffers ?
#La RAM est de 1 Go



Il vaut mieux augmenter ceci... Si c'est du myisam et qu'il n'y a
pas d'index fulltext, un passage en innodb peut augmenter
sensiblement les performances.

J'ai des bases de cartographie qui tournent très bien sur une Ultra1E
(170 MHz, Solaris9/32 bits, 640 Mo, raid1 software) et
sur des machines largement plus puissantes (debian, U420 quadripro).
Maintenant, Mysql est tatillon sur les accès disques et mémoire. En
passant d'un serveur bi-opteron (2,2 GHz, 4 Go de mémoire, Raid1
soft en U320) à un serveur bi-athlon (2,2 GHz réels, 4 Go de
mémoire, Raid1 soft en UDMA 133), je me suis pris (tout étant
identique par ailleurs) un facteur 20 de performance, la différence
étant entre les accès disques (c'est de l'UDMA...) et les accès
mémoires (contrôleurs externes). Bref, mysql est très tatillon sur
tout (contrairement à des outils style postgres) et personnellement,
je déconseille de plus en plus ce "truc" parce que les performances
dépendant à la fois du matériel (mais dans des proportions
aberrantes) et aussi de paramétrages fins du serveur. À partir d'un
certain moment, on ne sait plus vraiment ce qu'on fait.

Bref, en l'état actuel, augmentez les différents paramètres
correspondant aux différents caches (requêtes, jointures) pour que
les joitures puissent tenir dans ce cache (pour ne pas être
transcrites sur les disques).

log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See
README.Debian!
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 64M

[mysql]

[isamchk]
key_buffer = 16M

!includedir /etc/mysql/conf.d/





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.
G.Delafond
Le #21897691
Merci de vos réponses à tous.
J'ai monté toutes les valeurs de cache (j'ai repris les valeurs d'une
Mandriva qui tourne bien pour les mettre sur la Debian), mais sans aucun
résultat.
J'ai même ajouté quelques paramètres glanés çà et là. Idem.
L'histoire de ne pas faire travailler le disque, je comprends, mais pourquoi
ça fonctionne bien sur les autres machines ? Et pourquoi c'est ralenti en
réseau seulement ? (notez que je n'ai pas d'interface sur la machine
serveur, alors je ne peux pas juger si elle rapide en local).
On m'a aussi conseillé d'éviter le reverse-dns, mais pareil.

JKB wrote:

Le 21-04-2008, à propos de
Re: lenteur qt-mysql,
G.Delafond écrivait dans fr.comp.applications.sgbd :
JKB wrote:

Il serait bon de savoir comment le bazar mysql est configuré (par
exemple en donnant le fichier my.cnf). Mysql est une saleté à
configurer et à optimiser (je me demande si les verbes ne sont pas
en trop ici ;-) ). Par ailleurs, quel est le moteur de base ?
myisam, innodb, autre ?

En changeant l'un ou l'autre des paramètres, on arrive à changer le
comportement de mysql du tout au tout.

JKB



my.cnf
#
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently
parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#On peut peut-être jouer sur la taille des caches ou buffers ?
#La RAM est de 1 Go



Il vaut mieux augmenter ceci... Si c'est du myisam et qu'il n'y a
pas d'index fulltext, un passage en innodb peut augmenter
sensiblement les performances.

J'ai des bases de cartographie qui tournent très bien sur une Ultra1E
(170 MHz, Solaris9/32 bits, 640 Mo, raid1 software) et
sur des machines largement plus puissantes (debian, U420 quadripro).
Maintenant, Mysql est tatillon sur les accès disques et mémoire. En
passant d'un serveur bi-opteron (2,2 GHz, 4 Go de mémoire, Raid1
soft en U320) à un serveur bi-athlon (2,2 GHz réels, 4 Go de
mémoire, Raid1 soft en UDMA 133), je me suis pris (tout étant
identique par ailleurs) un facteur 20 de performance, la différence
étant entre les accès disques (c'est de l'UDMA...) et les accès
mémoires (contrôleurs externes). Bref, mysql est très tatillon sur
tout (contrairement à des outils style postgres) et personnellement,
je déconseille de plus en plus ce "truc" parce que les performances
dépendant à la fois du matériel (mais dans des proportions
aberrantes) et aussi de paramétrages fins du serveur. À partir d'un
certain moment, on ne sait plus vraiment ce qu'on fait.

Bref, en l'état actuel, augmentez les différents paramètres
correspondant aux différents caches (requêtes, jointures) pour que
les joitures puissent tenir dans ce cache (pour ne pas être
transcrites sur les disques).

log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See
README.Debian!
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 64M

[mysql]

[isamchk]
key_buffer = 16M

!includedir /etc/mysql/conf.d/





JKB




--
G.Delafond
http://www.delafond.org
Publicité
Poster une réponse
Anonyme