HTTP ERROR 500 Allowed memory size

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

  • [RÉGLÉ] HTTP ERROR 500 Allowed memory size

    Bonjour,

    Depuis quelques semaines, sur plusieurs PC, systématiquement dans n’importe quel navigateur internet, à l’ouverture de mon site je vois, selon le navigateur, sois une page toute blanche vide (Firefox), soit une page blanche (Chrome) avec le texte :
    "Cette page ne fonctionne pas Impossible de traiter cette demande via monsite.fr à l'heure actuelle. HTTP ERROR 500"
    Si j’actualise la page courante dans ces navigateurs, le site s’ouvre et fonctionne correctement.

    J’étais encore en Joomla 3.9.27. Je suis passé en Joomla 3.10.3 mais le problème persiste.
    J’étais encore en PHP 7.3.20. Je suis passé en PHP 7.4.24 mais le problème persiste.

    Si j’active le rapport d’erreur, je vois ces deux erreurs :
    - Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /home/xxx/www/libraries/joomla/database/driver/mysqli.php on line 894
    - Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /home/xxx/www/libraries/vendor/joomla/registry/src/Registry.php on line 89

    Dans le back-end, dans Informations système/Informations PHP :
    - memory_limit = 512M
    - post_max_size = 130M
    - upload_max_filesize = 128M

    Avec mon hébergement mutualisé chez OVH, je n’ai pas accès au fichier php.ini pour modifier le paramètre memory_limit.

    Mon site existe depuis 5 ans, pourquoi ce problème de mémoire apparait maintenant ?

    Comment puis-je solutionner cette erreur 500 ?

    Merci pour votre aide.
    Dernière édition par Micky701 à 21/11/2021, 22h39

  • #2
    Bonsoir
    avec un lien vers le site ce serait parfait pour faire des tests et nous rendre compte
    Ce qui est sûr c'est que ton site "consomme" trop de ressources apparemment
    Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez chaque jour ? Alors adhérez à l'AFUJ https://www.joomla.fr/association/adherer
    Cette année, le JoomlaDay FR a lieu à Bruxelles, les 20 et 21 mai 2022, plus d'infos et inscriptions : www.joomladay.fr

    Commentaire


    • #3
      Désolé, j'ai oublié le lien vers mon site : https://franchcountryinfos.fr/
      Je pense en effet que mon site consomme trop de ressources.

      Commentaire


      • #4
        Il y a peut-être un problème lié aux ressources (j'en vois pas tant que ça), mais la capacité du serveur à les traiter est probablement en cause également.
        Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
        Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
        Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

        Commentaire


        • #5
          Bonjour

          Une erreur 500 est une erreur serveur ==> peu importe le navigateur ou l'ordinateur utilisé, cette erreur 5xx est générée par le serveur.

          Fatal error: Allowed memory size of xxx bytes exhausted est l'une des pires erreurs qui puisse arriver en terme de compréhension : quelque chose a souhaité utiliser un peu plus de mémoire RAM et bardaf, de mémoire, y avait plus. Ce "quelque chose" peut-être un bête module qui souhaite juste quelques octets de mémoire. C'est lui qui a été le petite goutte de trop. "Quand yaplu ... yaplu..." (la valeur 536870912 correspond à 512 MB ce qui me paraît très correct).

          Dans ton administration de Joomla, tu peux activer le gestionnaire des erreurs (dans la configuration générale). Tente le coup de l'activation et réaffiche ton site. L'idée est d'obtenir ce qu'on nomme le debug strack trace càd un ensemble de lignes / fichiers par où est passé le serveur PHP pour exécuter ton script et afficher ta page. Il faudrait tenter d'y retrouver qui aurait été le gros consommateur.

          Si cela ne donne pas de résultat probant, tente une approche empirique : désactive tes modules... Est-ce mieux ? Oui, ok, on pourrait imaginer que ce soit un module précis qui est le très gros consommateur (avec la remarque que je fais ci-dessus concernant la goutte). Tu peux aussi tenter en désactivant les plugins de type contenu. Voire de changer de template. Tout ça temporairement le temps de trouver un bon coupable.
          Christophe (cavo789)
          Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
          Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

          Commentaire


          • #6
            Bonjour,
            Merci pour vos réponses.

            Christophe, je savais pour la signification de l’erreur 500, mais merci de l’avoir rappelé.

            Il y a quelques jours, j’avais essayé de désactiver le module jts_counterstats (de Sarki) pour lequel j’avais des doutes mais le problème persistait. J’avais désactivé quelques autres modules, les uns après les autres, mais sans succès.

            Dans le back-end, dans Configuration/Système je viens d’activer le paramètre Débogage système.

            1 - Résultat en relançant mon site :
            Dans Occupation de la mémoire, je lis : 8,90 MB
            Dans Profil d’information, je vois principalement 3 lignes en rouge :
            - Application : afterInitialise Temps : 354,54 ms Mémoire : 1,892 MB
            - Application : afterRenderModulemod_jts_counterstats (Statistiques d’accès) Temps : 4020,51 ms Mémoire :12,435 MB
            - Application : afterRender Temps : 1607,09 ms Mémoire : 0,269 MB
            Dans Requêtes de base de données : 45 requêtes exécutées en 4054,64 ms
            En cherchant la requête qui concerne jts_counterstats j’ai trouvé :
            Temps de requête : 3240,04 ms et Mémoire de requête : 157,522 MB !!!
            Les autres requêtes paraissent "normales".

            2 - J’ai de nouveau désactivé le module jts_counterstats
            En relançant mon site, l’erreur 500 persiste.
            Cette fois, dans Occupation de la mémoire, je lis : 8,80 MB
            Dans Profil d’information :
            - Application : afterInitialise Temps : 39,53 ms Mémoire : 1,908 MB
            - Application : afterRender Temps : 1686,91 ms Mémoire : 4,241 MB
            Dans Requêtes de base de données : 41 requêtes exécutées en 926,52 ms
            En regardant les requêtes, j’ai encore trouvé jts_counterstats :
            Temps de requête : 892,31 ms et Mémoire de requête : 135,759 MB !!
            Les autres requêtes paraissent "normales".

            3 - Je me suis souvenu qu’il y a un plug-in jts_counterstats !!!!!
            Je l’ai désactivé et je n’ai plus l’erreur 500.
            Cette fois, dans Occupation de la mémoire, je lis : 4,79 MB
            Dans Requêtes de base de données : 41 requêtes exécutées en 50,07 ms
            Je n’ai plus de requête de jts_counterstats et les autres requêtes paraissent "normales".

            Mes doutes concernant jts_counterstats (de Sarki) étaient donc fondés mais j’avais oublié le plug-in correspondant.
            J’avais déjà cherché à remplacer ces statistiques d’accès par une autre extension mais je n’avais rien trouvé de satisfaisant dans le JED.
            Tant pis !
            Merci Christophe pour ton conseil d’activer le débogage.
            cavo789 aime ceci.

            Commentaire


            • #7
              Bonjour,

              As-tu regardé JRealtime Analytics ?
              "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
              MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

              Commentaire


              • #8
                Cool ! Bravo pour avoir dénicher le coupable.

                Peut-être as-tu une table (associée à ce plugin) vraiment monstrueuse et que ce plugin charge l'intégralité en mémoire à chaque fois ? (Le développeur du plugin/module pourrait lui seul répondre / optimiser).

                Bonne journée.
                Christophe (cavo789)
                Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
                Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

                Commentaire


                • #9
                  Bonjour Robert,
                  Je n’avais pas regardé Jrealtime Analytics. Pour les statistiques complètes, j’utilise Matomo.
                  Je recherchais juste un simple plug-in pour afficher en front-end les statistiques d’accès comme jts_counterstats.

                  Christophe, dans phpMyAdmin j’ai regardé la table associée à jts_counterstats. En effet, elle est énorme !!
                  Je demanderai à Sarki.
                  Ce plug-in n’est pas compatible Joomla 4 et comme les statistiques de visites affichées sur le site sont passées de mode, je vais m’en passer.

                  Commentaire

                  Annonce

                  Réduire
                  Aucune annonce pour le moment.

                  Partenaire de l'association

                  Réduire

                  Hébergeur Web PlanetHoster
                  Travaille ...
                  X