Pb de traitement d'une grosse table de BDD

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] Pb de traitement d'une grosse table de BDD

    Bonjour,

    mon environnement : J 3.9.15, Php 7.4.2

    Dès lors qu'une requête mysqli dépasse un nombre de l'ordre de 4000 lignes sélectionnées dans une table pour être traitées, soit la requête se termine dans le vide, soit elle se termine après une trentaine de secondes poar une erreur 503.
    J'ai augmenté les valeurs des directives "pcre" de php, mais sans plus de succès (cf. pce.backtrack_limit & pce.recursion_limit).

    Question : quels paramètres convient-il d'augmenter pour pouvoir traiter au moins 25000 lignes sélectionnées par une requête mysqli ?

    Merci.
    Dernière édition par Visiteur à 07/02/2020, 13h16

  • #2
    Salut
    Ton probleme est vaste. En tout cas, mysql peut traiter enormement de ligne. En tout cas, bien plus que 4000.
    Comme ta requete te fournis une page vide, il va falloir afficher l'arret avec le display error a on, ou le rapport d'erreur a developpement.

    Comme ca a la louche.
    1. Requete mal forgée
    2. Table sans cle primaire ou index
    3. memoire allouée a la requete trop petite
    4. Temps alloué trop faible.

    Mais avec le peu d'information, c'est un peu de la roulette

    ++
    Wis

    Commentaire


    • #3
      Wismer

      Merci pour ton aide.
      Je me suis peut-être mal exprimé : quand je dis qu'une requête se termine dans le vide, je veux dire qu'elle se termine souvent en arrêtant le processus sans afficher de résultat.
      Pour répondre à tes points 1 à 4 :
      1. je vérifie l'écriture de la requête par un test préalable de bon fonctionnement avec phpmyadmin (donc son écriture n'est pas en cause),
      2. toutes mes tables possèdent à minima un id en auto-index,
      3. mémoire allouée : positionnée pour tests au maximum (avec l'hébergeur),
      4. temps alloué : idem

      Au niveau du déboguage, même en option "développement" je n'obtiens aucune information de dysfonctionnement.

      Un comble : un script des plus simples avec requête mysqli, sans aucun traitement des données sélectionnées ... ne donne aucun affichage de résultats et tourne très longtemps dès que le nombre de lignes sélectionnées excède environ 4300 !
      Dernière édition par Visiteur à 03/02/2020, 16h57

      Commentaire


      • #4
        Ok.
        Une page blanche signifie un arret brutal du php => il faut trouver la raison. Et malheureusement seul les logs peuvent te le dire.
        Il faut choper le rapport d'erreur d'apache.

        Si rien n'est possible, alors, il faut proceder par elimintation.
        Tu annulles toutes tes lignes que tu as rajouté puis apres tu les rajoutes une a une ( ou un groupe pour obtenir un resultat cohérent )
        Tu affichages un print_r('OK'); pour verifier que tu arrives jusqu'a cette ligne.

        etc..

        L'objectif est de trouver la ligne ou la fonction qui pose soucis.

        Si tu estimes que c'est la requete. Alors commente la ou remplace la par une reponse dont tu sais qui contient qu'une seule ligne " where id = 1"

        ++

        PS : Peux tu nous ecrire les lignes de programmation de ta requete?


        Commentaire


        • #5
          Wismer

          Je suis sensible devant tes efforts pour m'aider, et je t'en remercie vivement.

          Ce n'est nullement un problème de requête qui serait mal écrite : je confirme l'avoir testée avec phpmyadmin, et elle fonctionne très bien.
          Je suis un "routier" de l'informatique, et je connais bien toutes ces ficelles que tu me rappelles ici.
          Plus le temps passe et plus je pense que ce problème ne se situe pas dans mon script mais plutôt dans les données que je dois traiter : j'ai une table de 1 400 000 lignes issues d'un fichier national et dont les données personnelles ont été directement saisies par chaque personne concernée. Et à l'analyse de cette table, j'ai déjà décelé bien des anomalies (ex: saisie de caractères spéciaux, double guillemets, etc...). Le formulaire de saisie était vraisemblablement très permissif, et sans aucun contrôle des données archivées tel quel.
          J'ai déjà passé un temps considérable à effectuer des corrections, mais j'ai dû en oublier ... et je poursuis mes recherches de ce côté.
          J'ai segmenté ma table, et mon script unique fonctionne parfaitement avec certains segments non problématiques. Il me reste à fouiller dans les autres !

          Merci encore.

          Commentaire

          Annonce

          Réduire
          Aucune annonce pour le moment.

          Partenaire de l'association

          Réduire

          Hébergeur Web PlanetHoster
          Travaille ...
          X