Reprise du message précédent :
Samedi

quasi sur
Quand le serveur aura un peu plus de puissance, je pense que je passerais certaines tables en innodb pour éviter ce genre de lock.

Je l'ai dis, c'est lié à des deletes dans des gros topics.

c pas moi  

J'avais lu que les gros posteurs n'étaient jamais mass delete, justement que parce que le serveur roumain ferais une attaque dans la minute

supression de totoz =  

c'est peut etre une erreur de clic de la part d'un modo

Faut optimiser encore un peu

y a pas une commande pour passer la requete en arriere plan ?
 
Page générée en 71.516 secondes

N’empêche ca serait cool

fixed

Et ça restera dans la queue indéfiniment vu le nombre de requêtes ici

naaa, y aura bien un demi proc dispo de 4 a 6h

 
Y'a pas un système d'alerte pour détecter ça ?
Non parce que soit on supprime son compte sur HFR, soit on supprime 2/3 conneries, mais supprimer un gros paquet de posts, euh ?

 
Y'a quand même des tables pour historiser, enfin j'espère

M.arc faut pédaler plus vite le forum se traine là.

je sens bien la revente d'hfr a bolloré voir un hedge fund us

non
mais ca revient plus ou moins à tenter un passage en InnoDB pour avoir du row locking plutôt que du table locking

Ce n'est pas une question de CPU dispo ou autre, les CPU se tournent les pouces sur la BDD. L'arrière plan n'a pas de sens ici, la requête une fois lancée ne peut pas être morcelée ou faite quand y a un peu de temps libre entre tout le reste (MyISAM). Le lock de la table une fois acquis reste en place jusqu'à ce que ça soit terminé entièrement et s'il y a une ribambelle de choses à effacer ou à updater, comme pour un mass delete, bah le reste des requêtes des autres utilisateurs sur cette table vont s'accumuler en attendant la levée du lock et boum. D'où l'intérêt de passer en InnoDB comme Joce vient de dire pour locker les lignes en cours de modif uniquement (ce qui va très vite donc) et non pas la table entière, mais c'est + lourd que MyISAM... Il y a bien une gestion des priorités sur les select, update, etc., mais ça ne se fait que dans des cas bien particuliers où l'on est sûr que ça pourra s’exécuter à un moment donné. Ici, normalement, tout a une priorité identique et premier arrivé, premier sorti.

mes cours de BDD sont loin je t'avouerais, la plupart du temps au taf c'etait des betes jointures pas dans le bon ordre
 
ecrire un flag "post masqué" puis ensuite les delete (au moment du backup/apres celui ci, tout est alors encore locké) pourait gagner un peu ?

non, parce que c'est pas l'effacement du post qui prendre du temps pour le coup

la selection des posts c'est la meme requete que le filtrage interne par posteur, mais etendue ?
 
dans l'idée, parcourir en tache de fond une liste de messages pour flaguer les posts un par un, ca se fait discret, ca peut meme etre batché, une proc parcours la table a la recherche de trucs a traiter en priorité basse. le mec massdeleté etant prealablement interdit de poster, comme ca il fout pas la grouille pendant que la requete s'execute
 
si c'est direct "effacer tout ca, la dedans", ouais c'est sur que ca verrouille tout
dans mon souvenir, en se faisant chier un peu a l'ecriture on y gagne bcp a l'usage mais la jt'apprends rien
 
tu te rappelles encore comment ton bébé marche ou il a tellement évolué depuis que t'y touches plu qu'a part l'architecture generale ca ne ressemble plus a l'origine ?
 
en 2002, l'admiration qu'on avait pour la vitesse des forums PPC comparés a la concurrence était bien reelle
cet avantage reste aujourd'hui si on compare les besoins en ressources d'ailleurs, preuve de l'avance que t'avais pris a l'epoque...

C'est juste mysql qui a pas évolué donc, et maintenant que ça a été racheté

Tu veux morceler à la main finalement l'action en repérant par avance les posts à virer, tu mets les ID repérés dans une table, tu coupes le total en X morceaux et tu effectues X petites requêtes de DELETE plutôt qu'une grosse si j'ai bien compris.

Je connais toujours très très bien le code, t'inquiètes pas (il n'a finalement pas trop changé pour l'instant, il est juste un peu plus clean), et je peux vous dire que le problème n'est pas le delete en lui même (qui lui est déjà morcelé), et que ce qui coince n'est absolument pas morcelable

Le recalcul des index intratopic

CQFD

ou un gros batch delete en fin de backup
 
l'important étant que les posts massdeleté ne soient plus visible
apres, l'effacement reel peut etre pris en charge par un traitement différé au moment opportun.
 
décrit comme tu le fais, ca parait debile jte confirme et chui pas sur d'avoir décrit ca.
 
les posts sont incrementiels (nn° de sequence unique, jamais réutilisé. donc si le massdeleté ne peut plus poster, ce revient a flaguer des lignes en lecture seule...

tu me rassures

Le contenu de ce message a été effacé par son auteur

Malheureux, en dev info il ne faut jamais dire jamais, espèce d'inconscient.

Le problème c'est pas les procs, c'est les mutex et les locks

Le reste, c'est-à-dire la partie web via PHP/Apache pour générer les pages (après avoir reçu les données de la BDD pour les remplir) est pas mal gourmande en puissance brute. On peut mettre pas mal de choses en RAM pour limiter les I/O lentes sur les durs et les traitement répétitifs inutiles (fichiers php déjà précompilés notamment pour ne pas avoir à les réinterpréter à chaque page demandée ce qui serait très coûteux ici) mais ça reste un poste où il faut quand même de la patate niveau CPU.

Une BDD, c'est l'accès même aux données qui pose principalement problème, pas la puissance CPU, car tout le monde veut y avoir accès quasi simultanément, et hormis la lenteur relative du support physique, il y a des contraintes et des limitations pour garantir la cohérence de l'ensemble (les verrous qui ont été évoqués par ex.).

Ouais suppression de 6 messages par un modo dans un topic d'une page à 22h18, truc de ouf quoi, je comprends que ça plante, ça n'arrive jamais un truc aussi lourd

Et suppression d'un message à 22h26

P.S. : T'es pas au courant qu'il y'a des logs de modération sur MesDiscussions ?

Tout ce pataquès et x maintenances pour 6 messages

Ouch ça fait mal là  

Le contenu de ce message a été effacé par son auteur

flemme de regarder, je comptais sur toi
ceci dit c'était pas des petits deletes vu que c'était sur les premières page de topic géant (genre pour la requète que j'ai regardé, c'était sur le topic sarkozy, et il y avait plus de 484194 messages situés après le message effacé )

Faut splitter pour limiter la casse