Closed Fil closed 7 years ago
Voir aussi seenthis/seenthis_squelettes#149
Je pense qu'on peut fermer le ticket, en attendant que l'instance principale migre vers SPIP 3.1, il suffit de supprimer les index tag et spip_me_tags_index_tags de la table spip_me_tags.
@Fil as-tu supprimé les index en question sur seenthis.net ? Si non, tu veux que je m'en occupe pour qu'on ferme ce ticket ?
Non je n’ai pas touché à cet index. N’hesite pas :)
Le sam. 30 sept. 2017 à 19:29, b_b notifications@github.com a écrit :
@Fil https://github.com/fil as-tu supprimé les index en question sur seenthis.net ? Si non, tu veux que je m'en occupe pour qu'on ferme ce ticket ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/seenthis/hebergement/issues/12#issuecomment-333323474, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAbWQulIyEIWeZYxBEZEjzF1E_ka8Nsks5snnpvgaJpZM4JIbay .
Done, seul l'index tag(60)
était présent, je viens de le virer, on ferme :)
Hmm, je ne sais pas si ça vient de là, mais le load grimpe en flèche depuis que j'ai viré l'index en question, cf les graphes munin ci-dessous.
Après avoir vu le load exploser j'ai rétabli l'index en question, il faudra peut-être annuler ma modif dans la branche 3.1 si on observe le même comportement après avoir testé celle-ci sur l'instance de dev. En attendant j'ouvre le ticket de nouveau, et désolé pour la boulette...
Cette fois c'est bon, le bug est corrigé cf https://github.com/seenthis/seenthis_squelettes/issues/149#issuecomment-333637176
De ce que je vois sur le serveur, l'index spip_me_tags_index_tags
n'est pas présent :
MariaDB [seenthis]> SHOW INDEX FROM spip_me_tags;
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| spip_me_tags | 1 | uuid | 1 | uuid | A | 499160 | NULL | NULL | | BTREE | | |
| spip_me_tags | 1 | date | 1 | date | A | 748740 | NULL | NULL | | BTREE | | |
| spip_me_tags | 1 | id_me | 1 | id_me | A | 499160 | NULL | NULL | | BTREE | | |
| spip_me_tags | 1 | tag | 1 | tag | A | 998320 | 60 | NULL | | BTREE | | |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
À voir si on l'ajoute à la main pour être raccord avec ce qui est déclaré dans le plugin :
ALTER TABLE `spip_me_tags` ADD KEY `spip_me_tags_index_tags` (`class`,`tag`(255));
En attendant, je pense qu'on peut enfin fermer le ticket :)
bravo!
je pense que ce serait pas mal d'être raccord :)
@Fil je viens de tenter de créer l'index sans succès :
ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes
C'est peut-être pour ça qu'il n'était pas présent...
sur la page tag/xxxx on a cette erreur qui s'affiche, ça vient du tag(60) qui se glisse dans la jointure, un bug de spip probablement, ou alors de la déclaration de spip_me_tags ?.
J'ai viré l'erreur en rajoutant
{si 0}
dans la boucle suivante deseenthis_squelettes/noisettes/mots_lies/mots_lies.html
:Rien de grave, c'est juste la recherche des mots liés au mot qu'on regarde qui ne prend plus en compte les mots liés à travers des réponses. De toutes façons ce genre de calculs serait à refaire car plus la base grossit plus ça devient périlleux de faire ce genre de blague.