[RÉGLÉ] 504 Gateway Time-out

[Carmiel]

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.

[lomart]

Bonjour,

https://forum.joomla.fr/forum/joomla-3-x/installation-et-mise-%C3%A3%C2%A0-jour-de-joomla-3-x/226462-ovh-mises-%C3%A3%C2%A0-jour-joomla-3-7-1-3-7-2-qui-ne-passent-pas-sur-certains-serveurs

A en croire cette discussion, c'est le problème à la mode chez OVH
Bon courage

[Carmiel]

On se sent moins seul :-(

[RobertG]

Quelle est la taille de la base ?

[Carmiel]

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.

[lomart]

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

[Carmiel]

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,

[lomart]

En fait j'ai une table historique de acymailing qui fait 52Mo

cela n'explique pas les 162Go

[pjuignet]

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.

[jfque]

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 !

[manu93fr]

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.

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

[Carmiel]

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

[Carmiel]

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.

[RobertG]

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.

[Carmiel]

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