Reprise du message précédent :

oh que si, niveau fiabilite, et niveau perfs (sur des 15K)

avec le proc 64 bits qui va avec

C'est vrai que mon FX53 et ses deux disques SATA rendent bien

 
MySql estime qu'il n'est pas utile de prendre d'index pour A. Certainement que la requete doit retourner au moins 70% des enregistrements de 1.

 
 
Oh que si.

Alors justement, l'explain ne me renvoye aucune utilisation d'index pour la table C
Sinon, il me renvoye 2 rows sur environ 3000 Donc on est pas en dessous des 20 ou 30% de l'utilisation de l'index sur le nombre d'enregistrements (Oui bon, ma phrase veut rien dire, mais pense que t'as capté Joce )

Je fais la chasse aux index
 
J'ai une requête : ORDER BY champ1 DESC, champ2 DESC.
 
Si j'ai bien compris, un ORDER BY sur 2 champs tue complètement l'intêret des index Mais alors, comment faire ?

Tu fais ton tri en php avec usort.

Le coup du order by sur deux champ ca sent la liste de topic non ?

Connais pas du tout, je vais voir

J'ordonne par rapport à l'ID du dernier message d'un topic posté, et aussi par rapport au sujet sticky

je m'en doutais donc oublie USORT car si tu n'ordonne pas au moment de la requete tu va trier des topics qui ne sont pas ceux de la page voulues

Je disais ça pour rigoler hein...

C'est sûr ?
Parce que si je fais SELECT truc FROM topic WHERE Id_Cat = 1 LIMIT 0,30 ; a priori, je n'aurai qu'une liste de topic appartenant à la bonne page nan ?

Salope hého

bah c'est valide que si tu es sûr d'avoir exactement les données dont tu as besoin.
Si virer le tri de ta requête t'empêche de retrouver tes petits, tu arriveras à rien.
...et c'est beaucoup s'emmerder pour pas grand chose, encore...

Bah ds ce cas, comment se démerder directos avec MySQL ?

order by.

Mon problème se pose justement avec le ORDER BY

Oui, mais si tu veux ordonner des données en SQL t'as pas le choix.

tu mets un index compound sur les deux champs

J'vais voir ça, connais pas du tout le terme COMPOUND Merci du coup de main

 

 
=> c'est entre autres pour éviter ça que je limite dans le temps les possibilité d'édition / de suppression

Ma question aurait peut être plus sa place dans OSA, mais je tente quand même ma chance ici
 
J'ai un load average des plus normal, mais de manière totalement aléatoire (ça peut aussi bien le faire au bout de 48h que de 12 jours) la charge s'emballe sans aucune raison apparente :
 

 
Faudra que je fasse un TOP la prochaine fois que ça le fera. Mais j'ai déjà pu voir à peu près d'où vient le problème. Chaque fois qu'il apparaît et que je fais un show processlist, je vois un process initié par mon forum indiqué en "Sleep" depuis un nombre de secondes correspondant précisément au moment où la charge s'est envolée. Aucune connexion ne re-utilise jamais ce process. Si je le kille il apparaît comme "Killed" mais il ne disparaît jamais : la charge ne redescend à son niveau normal que si je reboote MySQL.
 
Pour l'instant je suis pas plus gêné que ça car même avec un load de 1.5 le forum se porte comme un charme, m'enfin c'est quand même pas rassurant. Si encore je pouvais reproduire le problème ... Mais comme il peut se passer 2 semaines sans qu'il n'y ait rien d'anormal je coince totalement
 
Quelqu'un a déjà vu ça ?
 
NB 1 : le graphe MRTG est intitulé Charge CPU mais il s'agit bien du load average
NB 2 : MySQL 4.1.11 EMT64

t'es sur que cette surcharge est en rapport avec ton forum? c'est pas plutot un bot qui passe sur ton forum et qui aspire toutes tes pages ?

Sûr et certain. Il y a une connexion qui reste ouverte pour une raison indéterminée et qui me bouffe plein de ressources.
 
Les bots c'est pas un problème (j'ai eu plus de 400 bots Yahoo au même moment la semaine dernière, le serveur n'a pas bronché )

Au niveau MySQL, pas de souci ? Ce ne serait pas un script sur une page très peu fréquentée qui tournerait en boucle infinie ?
 
Sinon, complètement HS, mais le query_cache est-il activé sur ton serveur ? Perso, j'ai constaté que query_cache activé, j'avais un load average plus elevé que sans ... Je ne sais pas si le gain est donc profitable au final ... T'en penses quoi ? (Toi qui a un gros serveur avec bcp bcp de monde dessus )

Un souci il y en a un. Mais je ne sais pas trop où chercher.
 

Boucle infinie non. Il n'y a pas de requête, juste un process qui reste en Sleep indéfinement, sans rien faire de visible. Si mon load average s'était envolé depuis une heure par exemple, un show processlist me donnerait ça :
 

Le Query Cache est activé oui. Ceci dit j'ai très longtemps tourné sur un MySQL 3.23 (sans QCACHE donc) et je n'ai pas vu de différence notable en passant à MySQL 4. Maintenant que j'ai davantage de monde et un forum un peu plus optimisé faudra que je fasse un test avec quelques heures sans tiens, le résultat pourrait être intéressant

quelle glibc ?
NPTL ou linuxthread ?

Aucune idée. Je m'occupe que de la partie développement, pas de l'administration du serveur, et je serais bien incapable de trouver ces infos
 
Ya quelque chose d'exploitable là dedans ?
 

ah en plus c'est une freebsd
dans le doute j'upgraderais en 4.1.12 perso

Limit ?  
C'est quoi ce truc que tu caches en bas de tes forums ?  
Tu t'es pas foulé pour l'intégration dans le design

en parlant de pb mysql space, moi j'ai toujours mon "bug" incompréhensible.
 
sur un dédié tout con ovh, j'ai une base invision qui tourne sans le moindre problème (processlist quasi toujours vide).
 
J'ai essayé de mettre cette base chez mon nouvel hébergeur, on a testé 4 serveurs différents et à chaque fois le résultat ressemble à ça http://ns3288.ovh.net/~dweis/processlist.htm :-/
on a testé avec la même version mysql que ovh (4.0.24) avec la même conf que chez ovh (et d'autres conf aussi). les 4 serveurs étaient vraiment différents (pas même conf du tout, pas meme kernel, pas même matos)...
 
une magnum de champomy (si ça existe) si quelqu'un trouve la solution

 
gaffe, les gens doivnt pouvoir avoir une possibilité d'acces et de rectification de leur donnée quelque soit la durée, c'est inscrit dans la loi

Tiens, en parlant de ça, je me demandais si la possibilité de voir les messages effacés du forum PPC par les modos n'était pas contraire à la CNIL. C'est pas pour chercher la merde, mais j'ai trouvé cette feature vachement intéressante (bien qu'un peu vicelarde) et du coup, j'ai voulu la rajouter sur mon forum et j'ai eu un tilt qui a toqué ma moralité.

Ca concerne les données nominatives

le problème c'est pas mysql, c'est phpMyAdmin (ah mince non tu parlais pas du problème des "array" )

 
ça veut dire quoi d'ailleurs ces "array" ?

c'est les données personelles comme celle qu'il y a inscrit dans le profil.
Mais ce topic etait fermé, comment ca se fait qu'avec la migration il a été re-ouvert? Sinon, est ce qu'il est possible d'editer un message d'un topic fermé ?

ca veut dire que les gars de phpMyAdmin savent pas coder, rien de plus