Caches sans fin

Bonjour,

j’ai 19 Spip chez Infomaniak, comme https://bettini.ficedl.info/ et autres.

Depuis la vague de bots, mes caches n’arrêtent pas de grossir. Je suis passé de 87 Go occupé à 250 Go (occupé à 97 %) en ayant régulièrement ajouté 50 par 50 Go.
Les sites sont tous Spip_WAP, mais ça ne suffit pas malgré son gros travail de filtre.
Infomaniak — hébergeur souverain — ne nous propose que des solutions extérieures CloudFlare ou AWS (Amazon) que nous ne pouvons accepter. Ce qui m’inquiète c’est la fuite en avant à racheter de la mémoire et de faire tomber le serveur SQl à presque plein temps.
Notre “serveur Cloud” 4 CPU 12 Go RAl serait insuffisant à 50 euros par mois et je en sais pas combien pour la mémoire disque rajoutée.

Est-ce les WAF qui saturent les disques. Je ne sais (peux en français de Paris) effacer leur cache et de toute façon, depuis ce matin plus d’accès http et ftp inaccessible, même renommer un fichier de 1.7Ko est “Timeout expired: 30000 milliseconds…“

Je leur est écris et attend une réponse.
Ce matin, Infomaniak m’a encore proposé

  • supprimer les données dont vous n’avez plus besoin
  • augmenter l’espace de stockage de votre Serveur:

passer mon temps à vider les caches spip, à ne pas réussir à vider ceux de WAF et à augmenter sans fin la mémoire disque, il y a un hic

le spip-check n’a rien trouvé et sur 2 des sites arrivés à plus 2 million de fichiers sans arriver au bout, j’ai laissé en 403 sans reprendre.

Claude

Bonjour,

Sans doute des choses qui ne tournent pas rond. Et comme tu parles de beaucoup de choses à la fois on ne sait pas d’où peut venir le problème.

  • 1ère chose → regarde le dossier « tmp » et dis nous ce qui s’y trouve
  • 2e → du -sh tmp → pour donner la taille du dossier tmp
  • 3e → ls -lhS → lister par taille.

Le mien fait 221M et c’est un site très fréquenté

Si tu as un cloud managé, active ACPU dans la config d’Infomaniak.
Puis mets le plugin Memoization et configure-le avec ACPU.

Et pfiou, plus de cache disque (puisque c’est un cache en RAM)

Le cache tmp/cache/calcul de SPIP ne peut pas gonfler par construction, donc je doute que ce soit ce cache là le problème.

Il te faut identifier quel répertoire est gros, lequel grossit effectivement (tmp? local? un autre ?) et dedans quel sous-répertoire… Cela peut donner des pistes…

Je ne sais pas si tu peux installer des commandes sur ton serveur, mais dust (GitHub - bootandy/dust: A more intuitive version of du in rust · GitHub) est extrêmement rapide à calculer les tailles de dossier (bien plus rapide que du)

Merci,
je suis sur le manager et j’y tourne en rond. Sa logique est surement très conviviale et ergonomique mais pas pour moi. bref, j’y tourne en rond.

Il me semblait avoir déjà trouvé ce paramètre ACPU qq part lors des réglages de de Spip_WAF mais je peux confondre.

@RealET bon, je suis parti ma balader et je me suis rappelé qu’il faut aller voir chaque site, etc. J’avait bien APCU activé (pas ACPU, coquille ?) mais pour installer et régler memoization, je vais devoir attendre un accès au serveur

Dyslexie :wink:

aujourd’hui, j’ai enfin pu avoir accès au serveur et aux sites entre deux pannes SQL, donc màj .27 et .28 et memoization paramétré. Plus qu’à attendre un peu voir la différence.

@marcimat,
je vais demander à qq1 de plus compétent que moi pour explorer ta proposition

et idem pour la proposition de Saidinou

bonjour, sur la question des caches, voici un courrier d’Infomaniak

Cela nous a demandé beaucoup de travail, mais nous sommes finalement parvenus à remettre votre serveur en état de fonctionnement.

Nos équipes ont effectué plusieurs vérifications sur votre Cloud et les sites concernés sont désormais à nouveau accessibles.

Nous avons constaté qu'un volume important de fichiers et de dossiers était présent dans le répertoire temporaire (tmp). Cette situation peut contribuer à des problèmes au niveau du système de fichiers. Nous vous recommandons donc de vérifier ce répertoire et de supprimer les fichiers temporaires qui ne sont plus nécessaires.

Pour limiter les sollicitations importantes de la base de données et améliorer la stabilité de vos sites, nous vous recommandons également d'optimiser la partie applicative. La mise en place d'un système de cache, par exemple avec Redis, peut notamment permettre de réduire le nombre de requêtes adressées à la base de données.


ceci n’empêche pas les sites d’avoir ce matin des messages d’erreur de type

Le système a rencontré une erreur lors de l’écriture du fichier ../tmp/cache/contextes//c4c7f855db1c2fa8a75e586466f795b13. Veuillez, en tant qu’admin du site, vérifier les droits d’écriture sur le répertoire tmp/cache/contextes.



ou

: file_put_contents(../local/cache-vignettes/L16xH16/69c94cbff318a6c47174891aa54b12-ec08f.svg.tmp): Failed to open stream: No space left on device in
/home/clients/a3580510d3989b69fb26134d5ef34fc5/sites/placard/ecrire/inc/filtres_images_lib_mini.ph

l’espace occupé est de 250Go sur 250 et je suis en train d’alléger.

Question de candide : est-ce que 18 spip sur une seule base est trop ? Y’ at-il une possibilité d’un moyen d’avoir une base pas site.
Les bases ont des noms comme XXX123_ficedl_bettini, XXX123_ficedl_bianco, etc.

Claude, qui n’a pas encore utilisé les méthodes proposées pour mesurer ces caches

Avoir une base par site c’est toujours mieux pour sauvegarder ou encore pouvoir facilement supprimer un site.

Ton erreur sur svg : tu mes à jour comment les sites ?

Ah mais tu as 18 SPIP sur le même hébergement (et 250Go pour l’ensemble des sites) ?

Faut vraiment regarder où tu as des Go en trop (des vidéos / images / pdf dans IMG/) ou du cache dans tmp/ ou local/ c’est pas la même chose.

SPIP-Cli (mais cela nécessite un shell) a quelques outils pour nettoyer de vieux fichiers de local/ par ailleurs (plutôt que de tout virer et nécessiter du coup ensuite beaucoup de CPU pour recalculer tous ces caches) images:purger du plugin images spip-cli/ImagesPurger.php · 0d6d340eafe103bde034c2417f65ee339ef7057e · spip / images · GitLab

@pierretux
mise à jour par spip_loader

J’ai actuellement 98 sites (en mutualisation) avec APCU sur un espace de « seulement » 250 Go occupé à 69% (171 Go).

Donc, ça devrait passer pour toi, non ?

1 « J'aime »