Problème requète mysq illogique

[programmeur]

ok, pourrais-je vous "tester" ?

voici un problème de TAILLE

cela fait TROIS SEMAINES que la série d'instructions mysql (permettant la sélection de certains champs propres à mes membres afin de leur envoyer des e-mails personnalisés) se met à BLOQUER carément le serveur malgré les usleep(100000) que j'ai bien pu mettre...

Alors, je me suis dit que c'était sans doute une requête particulière qu'il n'appréciait pas car souvent il bloquait anormalement au même endroit à la requête :

UPDATE webmasters set tmp_id = id, tmp_da = da, tmp_za = za, etc.

(ya environ 8 champs comme ça)

même si BIEN SUR ce n'est pas la SEULE qui bloquait... des requêtes comme des INSERTION sur une simple table... plantaient ! ou comme un autre type d'update également... DES TRUCS PAS LOGIQUES DU TOUT puisque sous l'interface PHPMYADMIN, les mêmes requêtes fonctionnent parfaitement...

Et bien, sûr, c'est UPDATE qui touche une base de 10.000 membres, soit 10.000 lignes, ce qui n'est normalement RIEN DU TOUT pour un serveur (j'en ai bien conscience)

Mais là... quand c'est le script PHP qui exécute ça , ça se BLOQUE...

Je sais pas pourquoi ! Pourtant, la même requête exécutée au même momnet sur l'interface PHPMYADMIN ne plante pas...

alors, qu'est-ce que c'est ???

Si vous arrivez à m'aider, ce sera chez vous que j'irai TOUT DE SUITE dès que mes revenus auront augmenté grâce à vous !!! si vous parvenez à me faire résoudre ce problème grave qui concerne tous les membres passionnés de mon site, devant subir une maintenance de deux à trois heures (que je fais moi-même en étant assez souvent obligé de rebooter le serveur tellement que ces "boucles infinies" produites par mysql sont étranges)...

pour info.... ma fonction requete_sql est faite comme ceci : effectivement, j'ai consu un mode DEBUG, lequel m'a permis de savoir avec PRESCISIOn que c'était bien les requêtes citées ci-dessus qui faisaient PLANTER le serveur (comme par hasard, requêtes de MISE à jour... jamais de sélection)

 

 function requete_sql($query, $fline = 0, $fname = "") {
 global $SITE, $webmasters_db; 

      
  if (!($SITE['connexion_sql'])) { die ("<u>Problème d'exécution de la requête</u> : <b>$query</b><br><br>Vous avez oublié de vous connecter via la fonction <b>connexion_sql()</b>..."); } 
      
          $i = 1; 

         $tquery = substr(strtoupper($query),0,6); 
      
         if (($SITE['ip_admin'] == $_SERVER['REMOTE_ADDR']) and ($SITE['debug_sql']==1)) { 

   $status = explode('  ',mysql_stat($webmasters_db));
   echo "<hr><b><u><font color=red>ETAT DU SERVEUR SQL</font></u> : <font color=green>";
   print_r($status);
   echo "</font></b> : <br><br>";
   echo "<b><u><font color=red>REQUETE SQL</font></u> (".basename($fname)." - ligne n°$fline) : <font color=blue>".$query."</font></b><hr><br>\r\n";
         }      

  $result = mysql_query($query,$webmasters_db);

  if ($SITE['pause_sql']) {

   //-- Pause de 1/10 de seconde pour REPOSER LE SERVEUR quand il y a TROP DE REQUETES A LA SUITE -->
   
   usleep($SITE['pause_sql']);
  }

  if (!$result) {

   deconnexion_sql();
   die('Problème dans la requête MYSQL...'); 

  } else {

   if ($tquery == 'SELECT') {

    while ($fetch_x = mysql_fetch_array($result, MYSQL_ASSOC)) {

     // $num[$i] = stripslashes($fetch_x);

     $num[$i] = $fetch_x;

     $i++;
    }

    mysql_free_result($result);

   } else $i = 2;
  }

  $num['count'] = $i-1;

  if (!$num['count']) { $num = 0; }

  return $num;
 }

cordialement

Modifié 23 Juin 2005 par programmeur

[Dan]

Salut Programmeur,

Il serait bon de connaître la requête que tu exécutes, avec la clause "WHERE" s'il y en a une.

De même que la structure de la table, les index et la version de mysql que tu tournes.

Dan

[Portekoi]

Bonjour,

D'accord avec Dan et de plus, est que tu as le même problème sans passer par ta fonction?

Portekoi

[programmeur]

Bonjour, je croyais pourtant avoir été explicite

C'est une requête "longue" mais sans where....

C'est un update d'une table totale de 10.000 enregistrements environ.

(mais d'autres requêtes se mettent également à planter sans raisons... comme des SELECT... (encore une fois sans where) mais pas tout de suite... au bout d'un moment... comme si une sorte de saturation quelconque s'installer, uniquement SUR LE SCRIPT... et ensuite, sur un navigateur comme MOZILLA, on voit écrit : TRANSFERT DES DONNEES EN COURS... et RIEN ne se transfert du tout !!!!)

Donc, sinon, ce genre de requêtes est exécutée normalement rapidement sur PHPMYADMIN (10 s maxi), mais elle plante lorsqu'elle est exécutée sur un script PHP.

c'est tout ce que je sais, et c'est un VRAI HANDICAP ce truc là !

et c'est indépendant de ma programmation...

c'est ça le pire !!!

donc, si quelqu'un s'y connaît en CONFIG SERVEUR LINUX !!!

[Portekoi]

Désolé de vouloir t'aider....

Et si cela venait de la config du serveur, ca le ferait aussi bien sous phpmyadmin que dans ton script php car... c'est la même chose...

La seule différence entre phpmyadmin et ton script, c'est la requete passe par ta fonction.

Donc ma question est : Est ce que ta requete fonctionne dans ton script sans passer par ta fonction.

De plus, si tu pouvais éviter d'ecrire COMME CA, ca serait sympa.

Merci

Portekoi

[programmeur]

excuse !

c'est que je suis un peu (même BEAUCOUP) sur les nerfs en ce moment car je perd maintenant plein de temps à essayer de comprendr eun bug qui m'échappe carément car illogique...

ma fonction requete_mysq a toujours marché en fait ! (et si je l'ai montré, c'était éventuellement pour que vous puissiez y découvrir une faille quelconque)

mais d'un côté, tu as raison... autant l'essayer sans passer par ma fonction pour gagner directement du temps (j'ai pas essayé ça car la fonction est excellente de toute façon mais c'est vrai que pour avoir la preuve absolue, il faudrait voir si ça plante sans la fonction effectivement je verrai donc ce soir ! si ça se trouve, les FONCTIONS des SCRIPTS PHP empêche la fonction mysql_query d'être à son maximum car encapsulé dans une zone mémoire propre à la fonction d'appel sous-jacente de la fonction ? non, là, c'est du délire lol)

donc, à moins que le phpmyadmin fasse des _AT_INISET

modifiant la config du serveur

je ne vois vraiment pas...

ps : tu vois des séquelles de programmation dans ma fonction ?

moi non...

salutations cordiales

Modifié 23 Juin 2005 par programmeur

[Portekoi]

Salut,

Là comme ca, je ne vois rien de spéciale sauf que je préfère faire une class à une fonction pour moins 'flexible'.

Par exemple, compter le nombre requete dans une page, avec le temps SQL et le script tu voies le truc...

Essaie et dis moi ce qu'il en est

A toute

Portekoi

[Boo2M0rs0]

Bonjour,

je ne sais pas quelle version de phpmyadmin tu utilises mais chez moi, lorsqu'il n'y a pas de clause limit, il rajoute automatiquement limit 0,30 à la fin de la requête.

Ca expliquerai le fait que tu as l'impression que c'est rapide sur phpmyadmin alors qu'en fait c'est une requête très lourde( enfin c'est mon avis et dans mes connaissances d'un vrai site, je n'ais pas la moindre idée de l'importance de ta base de donnés ).

[programmeur]

MERCI d'avoir tenté de m'aider

Une communauté de passionnés est parfois plus responsable que des pros (que j'ai payé 50 euros/jour)

J'ai COMPRIS mon problème !

ça commençait à m'inquiéter ! moi, qui n'ai jamais bloqué en programmation et qui suis normalement super rapide et rigoureux !!!!

en fait, c'était un bug inanticipable sans tester au PIF

la suppression des fichiers vides (permettant de stocker les adresses IP des visiteurs des palettes de populassite)

mettait presque une heure

d'où l'explication du problème de la purge de minuit !!!

donc, j'ai finalement délayé tout cela, en utilisant les CHMOD de linux, etc.

et voilà le travail !!!

quand on veut, on PEUT !!!!!!!!!!!!

en tout cas, l'ASTUCE, la GROSSE ASTUCE de renommer un répertoire rempli de fichiesr prennant plein de place en un répertoire nommé par exemple cache => cache2005-06-24

est carément sublime (c'est mon idée)

car elle permet de "déplacer" la lentur des traitements de la purge pour pouvoir, tranquillement en arrière plan, effectuer la suppression (pour vider le serveur de fichiesr inutiles, car je susi un maniaque et je déteste laisser des trucs qui prennent de la place chaque jour)

dnoc, la purge est CASI ULTRA RAPIDE

(avant, elle metttait 6 minutes THEORIQUES ET EFFECTIVES bien qu'elle PLANTAIT et ne pouvait donc pas envoyer tous les e-maisl à tout le monde !!!)

et maintenant, elle est carément génial car elle envoit TOUT EN DIFFERE et elle effectue EN MEME TEMPS les suppressions en différé

voilà le BON BOULOT ACCOMPLI

et là, j'ai plein de retours CRONS (volontairement mis pour suivre les purges pendant quelques jours)

et si je constate au bout d'une semaine que ça marche tous les jours

je ne recevrais plus les crons trop "triviaux" mais juste ceux de "conséquence final"

@++

[Anonymus]

Une communauté de passionnés est parfois plus responsable que des pros (que j'ai payé 50 euros/jour)

Des pros qui travaille à 50 par jour, ca ne court pas les rues. 50, ca correspond plutot à un tarif horaire... Ou alors, ce sont des pros qui ne résolvent pas les problèmes

[Sarc]

Sans vouloir jouer au modérateur à la place des modérateurs, je pense qu'il faudrait que tu fasses un travail d'écriture, qui pourrait peut-être permettre tant aux pros de 50 jour qu'aux passionnés du Hub de te lire correctement...

Des phrases ont un sujet, un verbe, un complément, et je doute que dans tes lettres officielles tu mettent des majuscules à tous les mots que tu veux accentuer (d'ailleurs, rarement dans les romans l'intonation est marquée à la taille de l'écriture)...

En fait, je dis ça parce que j'aurais aimé comprendre ton topic, comprendre la solution, pour pouvoir réagir rapidement si je suis confronté au problème plus tard, mais j'ai abandonné rapidement, car les lignes sautées, les signes de ponctuation, les majuscules, m'en ont empéchés...

Voilà, c'était mon gentil post, pour dire que je n'avais pas pu comprendre ce topic..