0000137: Crash base de donnée par Packet too large

Notes
(0000201) Marc77140 (reporter) 2005.08.16 18:05	Le problème était: chaque mise à jour de la base provoquait une disparition définitive de l'affichage des catégories ainsi que des commentaires et noms d'auteur. Aucune validation n'était possible.

(0000212) plg (manager) 2005.08.18 20:56 edited on: 2005.08.18 20:57	Je met de côté le premier problème lié aux fichiers images vides, pour me concentrer sur le plantage des requêtes car trop grosses. J'étais d'abord très étonné que cela puisse se produire en 1.3.0 (comme tu l'as indiqué) car ce qui pose certainement problème c'est la fonction synchronize_all_users qui remplit la table user_category, introduite en 1.3.1 pour améliorer les performances (ce qu'elle fait avec succès). Après avoir retrouvé l'adresse de ton site, je conclus que tu utilises en fait une 1.3.2 modifiée (notamment pour la gestion des EXIF). J'estime que tu as 25 catégories (en regardant ton menu), et 1700 utilisateurs. L'étude des fonctions admin/include/functions.php:synchronize* et admin/include/functions.php:update_user_category montre : - un code ultra lourd et complexe, avec 3 ou 4 profondeurs d'appel de fonction : >.synchronize_all_users >..\|-> get_plain_structure >..\|-> create_structure >..\|-> update_user_restrictions >..\|....`-> get_user_all_restrictions >..\|.........`-> get_user_restrictions >..`-> synchronize >.......`-> update_user_category >............\|-> update_user_category (recursivité = horreur) >............`-> update_uppercats Au bout du compte, la fonction synchronize execute une requête d'insertion de (nombre de catégories X nombre d'utilisateurs) lignes. Soit dans le cas de Marc77, 42500 lignes. Pour chaque ligne on insère 3 petits numériques et une date. En utilisant les valeurs maximales pour chaque champ, ça donne 24 octets (1 octet = 1 caractère) par ligne. Soit au final une requête d'un peu plus d'1 méga octet. Il s'agit évidemment d'une requête monumentale, mais on est encore loin des 4 ou 16 Mo, à moins que je ne calcule pas correctement. La bonne nouvelle : depuis la branche 1.4, la table user_category et l'enchevêtrement de fonctions décrit ci-dessus a été supprimé. Je suis revenu à une fonctionnement largement plus simple, et paradoxalement (?) plus rapide. La future/proche branche 1.5 conserve le principe de la 1.4. Sachant que tu utilises un forum + galerie sur ton site, je te conseille vivement de t'intéresser à la future 1.5 qui va te permettre de partager les comptes utilisateurs entre les 2 applications. La mauvaise nouvelle : n'ayant pas spécialement le temps, je ne modifierai pas la branche 1.3 qui est en passe de devenir la branche N-2. Marc77 a dit : > Ces problèmes sont la conséquence de l'absence de gestion > des erreurs qui peuvent se produire pendant la mise à jour > de la base dans le code de phpWG Effectivement, avant la branche 1.4, aucune notification d'erreur en cas de plantage d'une requête. C'est désormais clairement affiché, grâce à la fonction pwg_query (encapsulant mysql_query + affichage des erreurs). Je tire une leçon de ton problème : il faut mettre en place un garde-fou empêchant la génération automatique de requêtes monstrueuses. A partir de la branche 1.4, c'est uniquement à la fonction admin/include/functions.php:mass_inserts que je dois m'intéresser pour éventuellement découper les insertions en plusieurs paquets. Merci de nous avoir fait part de ton problème, de ton étude et de sa résolution.

(0001770) laurent_duretz (developer) 2007.02.16 16:21	la fonction mass_inserts a été modifiée pour récupérer la taille max d'une requête SQL.

Issue History
Date Modified	Username	Field	Change
2005.08.16 14:45	Marc77140	New Issue
2005.08.16 14:45	Marc77140	browser	=> Mozilla
2005.08.16 14:45	Marc77140	Web server	=> Apache 1.3.x
2005.08.16 18:05	Marc77140	Note Added: 0000201
2005.08.18 20:56	plg	Note Added: 0000212
2005.08.18 20:57	plg	Note Edited: 0000212
2005.08.18 21:01	plg	Assigned To	=> plg
2005.08.18 21:01	plg	Status	new => assigned
2005.08.18 21:01	plg	Resolution	open => won't fix
2005.08.18 21:01	plg	version	1.3.0 => 1.3.2
2007.02.08 10:44	plg	Assigned To	plg => laurent_duretz
2007.02.16 16:21	laurent_duretz	Status	assigned => resolved
2007.02.16 16:21	laurent_duretz	Fixed in Version	=> 1.7.0RC1
2007.02.16 16:21	laurent_duretz	Resolution	won't fix => fixed
2007.02.16 16:21	laurent_duretz	Note Added: 0001770
2007.02.16 18:16	plg	Status	resolved => closed

Relationships