504 Gateway Time-out

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

  • [RÉGLÉ] 504 Gateway Time-out

    Bonjour,
    Mon site est hébergé par OVH. Je suis passé de PRO à Performance1 et je galère avec la base sql privée.
    J'arrive maintenant à la migrer en utilisant un script bigdump.php mais après la migration j'ai eu des erreur "504 Gateway Time-out".
    J'ai fait un retour arrière, ce qui confirme que c'est bien la base privée.
    Ceci étant, maintenant j'en ai aussi en étant sur la base mutualisée, à part que celles là ne sont pas permanentes.

    OVH me dit d'optimiser ma base. C'est bien mais avec Joomla comment faire, je ne maîtrise pas les tables ni le code php.
    J'ai trouvé un script qui est censé le faire sur toutes les tables, mais il se termine en erreur 504, donc je ne suis pas avancé.

    Avez-vous une solution à me proposer ?

    Merci d'avance pour votre aide.
    Dernière édition par Carmiel à 20/04/2018, 08h33

  • #2
    Bonjour,


    A en croire cette discussion, c'est le problème à la mode chez OVH
    Bon courage
    UP, le plugin universel à découvrir sur https//up.lomart.fr
    bgMax
    , AdminOrder, MetaData, Zoom, ArtPlug, Custom, Memo, Filter, ... sur http://lomart.fr/extensions

    Commentaire


    • #3
      On se sent moins seul :-(

      Commentaire


      • #4
        Quelle est la taille de la base ?
        "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


        • #5
          elle fait 162 Go et en restaurant sur la privée 118 Go. Je suppose que la différence ce sont des informations de cache.

          Commentaire


          • #6
            Il faut aller voir avec phpMyAdmin les tables qui consomment le plus. Il suffit de cliquer sur le titre de la colonne "Taille" pour le savoir
            UP, le plugin universel à découvrir sur https//up.lomart.fr
            bgMax
            , AdminOrder, MetaData, Zoom, ArtPlug, Custom, Memo, Filter, ... sur http://lomart.fr/extensions

            Commentaire


            • #7
              Je viens de regarder (il y a une colonne taille dans l'affichage en liste).
              En fait j'ai une table historique de acymailing qui fait 52Mo la table des répétition de jevent et la table users.
              La première je vais voir avec l'aditeur, j'ai un contrat,
              jevent je vais réduire la durée de génération à un an, ça suffira?
              Pour users je ne peux pas faire grand chose sinon que de purger tous les adhérents qui ne sont plus actifs.
              J'ai aussi la géolocalisation de acymailing, mais ça je vais purger et ne plus la mettre en oeuvre, ça ne me sert à rien.

              J'ai aussi des tables avec beaucoup de ligne mais pas forcément en taille, je vais vois à purger ce qui peut l'être.

              Bon, je vais faire ça et je reviens.
              merci du conseil
              A suivre,

              Commentaire


              • #8
                En fait j'ai une table historique de acymailing qui fait 52Mo
                cela n'explique pas les 162Go
                UP, le plugin universel à découvrir sur https//up.lomart.fr
                bgMax
                , AdminOrder, MetaData, Zoom, ArtPlug, Custom, Memo, Filter, ... sur http://lomart.fr/extensions

                Commentaire


                • #9
                  Sur ce sujet, j'ai le même problème avec OVH
                  Admin Tools offre un outil d'optimisation des tables, mais arrivé à un certain pourcentage, le 504 gateway Time-out coupe la connexion.

                  Commentaire


                  • #10
                    Je pense qu'il y a une erreur dans la taille annoncée de la base de données : l'hébergement Performance 1 ne permet que des bases de données de 800 Mo ou une de 4 Go.
                    Et si c'est vraiment 160 Go, il faut autre chose qu'un hébergement mutualisé à 10 €/mois !
                    Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
                    Administrateur certifié Joomla! 3
                    https://www.betterweb.fr

                    Commentaire


                    • #11
                      Envoyé par pjuignet Voir le message
                      Sur ce sujet, j'ai le même problème avec OVH
                      Admin Tools offre un outil d'optimisation des tables, mais arrivé à un certain pourcentage, le 504 gateway Time-out coupe la connexion.
                      Cliquez sur l'image pour l'afficher en taille normale

Nom : 504 Gateway.jpg 
Affichages : 323 
Taille : 16,2 Ko 
ID : 1980199
                      l'erreur 504 Gateway = a plus de 90% OVH Mutualisé
                      Donc si tu ne veux plus te prendre la têête avec ça ... y a plus qu'a
                      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


                      • #12
                        Oups, oui il s'agissait bien de 160 Mo et pas Go, ce qui est déjà pas mal
                        une centaine dans 4 tables.
                        ##_acymailing_history 53 Mo
                        ##_jevents_repetition 28 Mo
                        ##_users 15 Mo
                        ##_acymailing_userstats 13Mo
                        Dernière édition par Carmiel à 20/04/2018, 20h33

                        Commentaire


                        • #13
                          Bonjour,
                          j'ai purgé des tables pour atteindre 86 Mo.
                          Maintenant j'ai un autre problème.
                          J'ai fait une erreur de débutant, j'ai demandé le service de base privée en 5.7 alors que l'original est en 5.6. Grossière erreur de ma part.
                          Cette version intègre des contrôles d'intégrité supplémentaires par rapport à la V5.6, ce qui fait que la restauration génère encore des erreurs.
                          Notamment sur les dates. par exemple ça il n'aime pas lors de la création
                          `valid_to` datetime NOT NULL DEFAULT '0000-00-00 00:00:00'

                          j'ai remplacé dans la création par
                          `valid_to` datetime NOT NULL DEFAULT '1970-01-01 00:00:00'

                          Le problème c'est dans les INSERT, j'ai rajouté IGNORE, mais ça veut dire qu'il ignore tout et du coup ça rend la restauration incertaine.
                          J'essaye de les contourner, mais ne pas restaurer de bout en bout sans erreur ne garantit pas que la base restaurée est saine.
                          En l'occurrence, elle ne devait pas l'être car j'ai eu une erreur "Error" (c'est comme appeler son chien 'le chien' ).
                          J'ai demandé la recréation du service à OVH en 5.6, mais je ne sais pas encore s'ils vont dire OK.
                          Le downgrade n'est pas possible dans l'interface admin, seulement la montée de version.

                          Depuis le ménage je n'ai plus de time-out sur l'ancienne base, mais ça ne veut rien dire, c'était la nuit et maintenant c'est samedi, je verrai à l'usage.

                          Commentaire


                          • #14
                            Je viens de travailler ces jours-ci sur un Uwamp en local, sur MySQL 5.7, sans aucun incident lors d'import de base.
                            De quelle date parles-tu ? La date de fin de publication d'articles est la plupart du temps vide, donc sous cette forme '0000-00-00 00:00:00', je viens de le vérifier sous cette même version de MySQL

                            INSERT IGNORE veut dire que les données existantes ne génèrent pas d'erreur lors d'un nouvel import, et, sauf erreur de ma part, la ligne est remplacée si elle existe déjà, donc a priori dans ton cas, aucun souci.
                            Par contre, selon les extensions, il peut être impératif de désactiver la gestion des clés étrangères à l'export puis à l'import.

                            Au fait, le simple message "Error" a souvent été signalé ces derniers temps chez OVH, signe de problème sur le serveur et ne de mandant que de la patience pour que les choses rentrent dans l'ordre.
                            "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


                            • #15
                              C'est comme j'ai écrit en bleu, la création de la table donne une erreur sur le format de date par défaut.
                              Mais ça à la limite je pourrais remplacer "000-00-00 00:00:00" par NULL, ça semble accepté.
                              Il râle par exemple sur la table users qui contient des dates en "000-00-00 00:00:00", sauf si je met IGNORE, mais par contre il va ignorer tout et peut-être masquer d'autres erreurs qu'il ne faut pas ignorer.

                              Je vais retenter ce soir la migration, j'espère que je n'aurai pas de Error

                              Commentaire

                              Annonce

                              Réduire
                              Aucune annonce pour le moment.

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X