Bonjour,
Depuis quelques semaines j'ai des pb avec ma photothèque installée depuis plusieurs années sur mon site internet, une erreur "Error 503 Backend fetch failed". Cela "plante" la photothèque et le site.
Dès que je mets la photothèque en mode maintenance plus de pb... et le site tourne correctement.
Avec un technicien de l'hébergeur Gandi, on a fait des recherches mais rien n'est concluant !
Auriez-vous une idée, une piste ?
merci de votre retour
Benoît
Environnement
Piwigo 16.2.0
Installé le 20 mars 2017, il y a 8 ans 10 mois 4 semaines 2 jours
Système d'exploitation: Linux (container)
PHP: 8.2.29 (Montrer les informations) [2026-02-19 09:47:24]
MySQL: 5.7.23-23-log [2026-02-19 09:47:24]
Bibliothèque graphique: External ImageMagick 6.9.11-60
Taille du cache 1875.91 Mo calculé il y a 14 minutes
URL Piwigo: https://www.planete-urb.com/URB_Photos/
Hors ligne
Bonjour,
D'après cette recherche : https://duckduckgo.com/?ia=web&orig … tch+failed
on y parle de surcharge du serveur, de cache etc, et le cache fait 1875.91 Mo (presque 2 Go).
Mais si le tech n'en parle pas, ce n'est peut-être pas la cause.
Hors ligne
Question de néophyte, on ne peut pas réduite la taille du cache Piwigo ?
en effet, 2 Go me semble important ! mais peut-être nécessaire ...
Hors ligne
Le cache correspond aux variantes de vos photos (appelé "Derivatives" |EN]) et correspondantes aux différents formats de photos photos.
Le cache peut être vidé sans problème. Les variantes ne sont créés que sur instruction explicite mais surtout lors des visites de vos visiteurs.
Plus vous avez de photos dans des tailles différentes, plus le cache sera important.
Hors ligne
Bon, en faisant un peu de ménage, en supprimant qq tailles multiples des photos, j'ai réduit le cache à moins de 900 Mo...
... mais ça plante toujours !
Hors ligne
Ca ne vient pas de Piwigo. Faites une recherches et vous verrez que c'est du ressort de l'hébergeur.
Hors ligne
Bonjour
Taille de la base de données ? taille maximum de la basse de données ?
Hors ligne
"Ca ne vient pas de Piwigo. Faites une recherches et vous verrez que c'est du ressort de l'hébergeur."
hum... on a déjà fait pas mal de recherche,
après analyse des fichiers logs, on a constaté que le site (wordpress) fait actuellement l'objet d'un crawl intensif par des bots, notamment ceux utilisés pour l'entraînement de moteurs d'intelligence artificielle.
on a modifié le fichier .htaccess en conséquence.
Mais je ne peux pas dire que cela à résolu le pb !
Le fait est que mon site wordpress fonctionne très bien quand la galerie est verrouillée, et plante quand elle et active (ainsi que la galerie)
Une question : est-il possible de revenir à une version antérieure de piwigo ?
Concernant la taille de la BDD, je ne sais pas où la trouver...
merci pour votre retour
Hors ligne
Avec des adresses de sites en sous-domaines au lieu de sous-répertoires, il y aurait peut-être moins de souci. Bien sûr, si l'on rectifie aujourd'hui, cela casse tout le référencement, mais il aurait fallu l'envisager dès le départ.
Quand j'ai créé mes 1ers sites il y a 20 ans, je m'étais aperçue qu'avec mes sites qui avaient des url en sous-répertoires il y avait confusion de cookies dans le navigateur entre ceux des différents sites et donc j'avais rectifié vite fait. Ce n'est peut-être pas ton souci actuel, mais c'est la raison pour laquelle j'ai choisi l'option des sous-domaines au tout début de ma "carrière" de webmestre.
La taille de la base de données se trouve dans ton compte chez ton hébergeur.
Hors ligne
Je viens de m'apercevoir que le fautif dans la prise de poids (que dis-je : un serpent aussi gros qu'un hippopotame) n'est pas tant les dérivatives mais... les logs ! Ils sont de base mal réglés.
https://github.com/Piwigo/Piwigo/pull/2526
Solution immédiate :
1. Via LocalFiles_Editor, rajouter ces lignes :
// Log level (OFF, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG) // development = DEBUG, production = ERROR $conf['log_level'] = 'ERROR'; // Keep logs file during X days $conf['log_archive_days'] = 1;
2. Laisser passer 24h
3. Revenez sur votre code précédement inséré et supprimez :
// Keep logs file during X days $conf['log_archive_days'] = 1;
Cela va permettre de retrouver un état normal et de vider naturellement les fichiers sans la moindre intervention sur les fichiers.
Sinon, sans plus attendre, il suffit de corriger la variable log_level et de supprimer les fichiers ./_data/*.logs
Cela représentait déjà 2 Go chez moi en l'espace d'un mois.
Dernière modification par Gotcha (2026-02-21 08:24:04)
Hors ligne
Merci pour cette suppression de prise de poids des logs ;)
ça marche, pour autant j'ai toujours mes pb de blocage du site !
Je me permets de réitérer ma question :
Une question : est-il possible de revenir à une version antérieure de piwigo ?
Je tenterai bien cette option
Merci pour votre aide
Hors ligne
Non ce n'est pas prévue ni souhaité. L'ancien code ne peut s’accommoder des nouveautés apparues entre temps et qui sont installées sur votre hébergement en fichiers et surtout en base de données.
Donc à moins de repartir de zéro...
Hors ligne
Merci pour le retour !
Sinon, pour en reprendre un autre, "Ca ne vient pas de Piwigo. Faites une recherches et vous verrez que c'est du ressort de l'hébergeur."
Vers quoi vous pourriez m'orienter ? car, c'est un peu l'aiguille dans une botte de foin ;)
Hors ligne
C'est du ressort de l'infrastructure/hypervision (votre hébergeur). Il y a quelque chose qui bloque la bonne exécution du code.
Lui seul à les outils de monitoring et de suivi pour dire précisément ce qui déclenche ce blocage. C'est LUI qui bloque, pas Piwigo ni le Saint Esprit. Si votre fournisseur n'a pas idée, c'est que... il est temps d'envisager un fournisseur plus sérieux ;-)
→ Je ne détiens pas la solution, ce n'est tout simplement pas ma partie.
Hors ligne