requête aléatoirement longue, après un arrêt du service c'est reparti?

[xsasiela]

Bonjour à tous,

J'ai un problème qui me fait tourner en bourrique!

J'explique: j'effectue 2 requêtes relativement lourdes à la suite, 2 insert dans une table à partir d'un select (en innodb). Cela traite quelques millions lignes et le tout doit prendre 1 heure en temps normal.

Depuis quelques temps, sans modification des 2 requêtes, le temps d’exécution passe à 5h, 11h, ... etc... et peut revenir à 1 h de manière inexpliquée.

J'ai essayé plusieurs config mémoire mais rien n'y fait, et si je charge la même base sur un poste lambda ça fonctionne....!! alors que ça va durer des plombes sur le serveur qui déconne! Bien entendu les tests sont fait quand rien d'autre ne tourne sur le serveur utilisé et avec un même jeux de données.

Le seul palliatif qui a l'air de fonctionner c'est d'arrêter et de relancer le service.

Précision: ça tourne sur un mysql 5.1 en innodb. Je vous mets la config du serveur de prod mais ça fonctionne très bien sur un poste lambda avec une installation de base (quand ça fonctionne):

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
 
default-character-SET=latin1
 
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
 
max_connections=100
 
query_cache_size=512M
 
table_cache=4096
open-files-LIMIT=4096
 
tmp_table_size=1024M
 
thread_cache_size=8
 
myisam_max_sort_file_size=100G
 
myisam_sort_buffer_size=369M
 
key_buffer_size=128M
 
read_buffer_size=64K
read_rnd_buffer_size=256K
 
sort_buffer_size=64M
 
 
innodb_additional_mem_pool_size=50M
 
innodb_flush_log_at_trx_commit=1
 
innodb_log_buffer_size=32M
 
innodb_buffer_pool_size=7G
 
innodb_log_file_size=1G
 
innodb_thread_concurrency=18
 
max_allowed_packet=16M
 
binlog-cache-size=256M
 
innodb_lock_wait_timeout=300
 
optimizer_search_depth=6

[ericd69]

salut,

quand tu vois vois que ça dure trop longtemps, regarde quels processus tournent... des durées d'exécution aussi longues et variables laissent penser à un ou des trucs qui se lancent à ce moment là...

[NicoD.]

Le serveur que tu utilises est consacré 100% à ta base de données ou bien est-il utilisé pour autre chose en parallèle ?

[CinePhil]

Regarde aussi si ta BDD est bien indexée car ça fait quand même très très long !

[xsasiela]

pour vous répondre:
- le serveur de prod est dédié mysql, et quand je recharge sur un serveur de test, rien d'autre ne tourne pour mes tests
- les index sont bien gérés

encore une fois le problème est aléatoire, quand je monitore le système via les outils windows il en résulte une charge processeur constante autour de 13% (seul le mysql tourne à ce moment là) avec des accès disque en lecture/ecriture très lent (actions de lire ou d’écrire), alors qu'en fonctionnement normal le processeur pousse des pointes régulières et les accès lecture/ecriture disque sont très nombreux et fréquent.

Par contre, en essayant un simple arret/restart du processus mysql tout est redevenu dans l'ordre...???? depuis 1 semaine cela refonctionne. Fuite mémoire mysql? problème de paramétrage de purges de données temporaires? bizarre quand même.

voici le seul lien que j'ai trouvé et qui définit bien mon problème (c'est en anglais).
http://forums.mysql.com/read.php?24,43796,43796

[xsasiela]

Pour alimenter l'eau au moulin, il s'est avéré que le redémarrage seul du service mysql ne résout pas toujours le problème. Par contre, nous avons détecté une nouvelle manière depuis ce matin pour résoudre le problème :

sur la base mysql en question, nous avons 2 applis qui peuvent y accéder (via hibernate). Le batch qui bloque passe quand ces 2 applis ne font rien, mais nous avons testé de couper une des 2 applis et les choses se débloquent, je précise qu'il n'y a pas de verrous mortels et que nous nous assurons bien que aucune des 2 applis en question ne fait rien. Malgré cela, le fait de couper une appli, et donc de killer les connexions liées, a l'air de libérer les ressources de mysql pour bien faire passer le job qui bloque.

Quelqu'un sait-il s'il y a une retenue mémoire particulière sur chaque connexion et s'il y a un paramétrage pour gérer ça proprement ?

[Yanika_bzh]

Il paraît probable que votre souci ne vienne pas de votre serveur mais des applis clients non ?

[Sethenssen]

Bonjour,

Il faut mettre

Code :

innodb_flush_log_at_trx_commit=0

Si la valeur est à 1 il va écrire à chaque entrée sur le disque
Tu gagneras un peu en temps de traitement ainsi.

[xsasiela]

Bonjour A tous,

une nouvelle étape dans l'analyse de notre problème,... qui nous perd encore un peu plus car nous n'arrivons pas à avoir une résolution stable à notre problème.

nous chargeons un dump de prod sur un serveur dédié à l'utilisation de notre batch d'import sous mysql 5.5 ( alors que en 5.1 en prod), rien d'autre ne vient taper dessus que notre batch d'import: verdict le problème se reproduit.

Nous avons tenter un rédémarrage du service mysql: pareil
nous avons tenter toute la collection des flush (logs, master, etc...): pareil
nous avons tenter un redémarrage sur serveur: et là Oh miracle ca refonctionne correctement!

je résume:
- redémarrage du service mysql, fonctionne quand ca veut mais pas imparable
- coupure des connexions clientes autres que notre batch d'import: fonctionne mais pas imparable
- redémarrage sur serveur windows: c'est le dernier test qui à l'air de fonctionner quand les autres tentative ne fonctionnent pas mais impossible à mettre en prod sur un serveur de prod

Quelqu'un serait au courant de problème mysql/windows (32 ou 64bits ca change rien au problème)?