hello,
tout est go dans le titre,
quelque chose a t-il changé dans la gestion du cache,
php4 peut il expliquer la chose ou bien?
une piste pour tracer le problème?
merci, pierre
un robot fou qui a pris SPIP de vitesse et l'a fait passé le seuil de non retour.
Il faut vider le cache à la main (et tu verra que ça va etre très dur), et utiliser l'ecran de sécurité (pour eviter d'avoir un nombre infini d'urls par pagination croisées), ou voir si tu n'as pas un loup dans ton skel qui générerait un nombre infini d'urls...
Cédric
Egalement, utiliser memoization qui n'a pas de problème de garbage collector
Pour ça, si tu as un shell, tu peux te tenter des choses tel que :
Supprimer un énorme dossier lorsque rm indique qu’il y a trop de fichiers :
Se mettre dans le dossier puis (pour des fichiers dont les noms utilisent des caractères hexadecimaux) :
for i in `seq 0 9` a b c d e f; do for j in `seq 0 9` a b c d e f; do echo "Suppression de $i$j*"; rm $i$j*; done; done
helllo,
non je n'ai pas d'acces shell je suis en mutualisé sur altern
je purge avec la pompe ?exec=admin_vider 
j'ai vérifié mes squelettes, supprimé des rss possiblement coupables d'afficher trop d'url,
sans incidence
j'ai le sentiment que le cache ne se vidait juste pas.
Après installation de memoization, il semble que le problème lenteur d'affichage des pages publiques
lié à l'énormité du cache soit diminué, en espérant que ce cache est bien géré maintenant,
n'ayant plus d'indication quant à sa taille dans ?exec=admin_vider
merci pour vos réponses, bon dimanche, pierre
Après installation de memoization, il semble que le problème lenteur
d'affichage des pages publiques
lié à l'énormité du cache soit diminué,
oui
en espérant que ce cache est bien
géré maintenant,
n'ayant plus d'indication quant à sa taille dans ?exec=admin_vider
en effet il n'y a plus d'indication, il faudrait y travailler
séparément pour chaque mode de mémoization. Lequel as-tu choisi ?
merci pour vos réponses, bon dimanche, pierre
Demande éventuellement à un admin de ton alternc qu'il supprime les
fichiers tmp/cache/?/* (le ? signifiant un seul caractère), car je ne
crois pas que SPIP pourra le purger tout seul.
-- Fil
Après installation de memoization, il semble que le problème lenteur
d'affichage des pages publiques
lié à l'énormité du cache soit diminué,oui
en espérant que ce cache est bien
géré maintenant,
n'ayant plus d'indication quant à sa taille dans ?exec=admin_videren effet il n'y a plus d'indication, il faudrait y travailler
séparément pour chaque mode de mémoization. Lequel as-tu choisi ?
auto-detection filecache, je n'ai pas creusé 
Demande éventuellement à un admin de ton alternc qu'il supprime les
fichiers tmp/cache/?/* (le ? signifiant un seul caractère), car je ne
crois pas que SPIP pourra le purger tout seul.
hi hi, l'administrateur, il pêche et il jardine aujourd'hui
toujours en php4, sûr que ça n'a pas de lien avec ce pb de cache?
merci Fil
auto-detection filecache, je n'ai pas creusé
un peu dommage, c'est le moins performant (il a la même performance
que le cache de spip, problème de garbage collector en moins)
toujours en php4, sûr que ça n'a pas de lien avec ce pb de cache?
non, je ne pense pas qu'il y ait de souci php4 à ce niveau
-- Fil
Ce matin je constate une mésaventure similaire même si il y a moins d'ampleur : un cache de 750 Mo qui contient des centaines et des centaines de fichiers et qui enfle, enfle, enfle...
J'ai donc mis mon client FTP à la tâche pour vider /tmp/cache et ça l'occupe grave ! En fait je me demande même si il va s'en sortir ...
C'est dû à quoi ce genre de dérapage ? Comment l'éviter ? C'est quoi ce memoization dont il a été question dans un mail précédent ?
Merci pour votre aide...
Emmanuel GUILLEMONT
C'est dû à quoi ce genre de dérapage ?
hé bien SPIP dispose d'un mécanisme pour vider le cache régulièrement
dès lors qu'il devient trop plein. Mais ce mécanisme peut échouer si
la cache est devenu trop gros, et quand le système n'arrive plus à
donner assez vite à SPIP la liste des fichiers présents dans le cache
(et donc, à supprimer).
Comment l'éviter ? C'est quoi ce
memoization dont il a été question dans un mail précédent ?
développé ici
et en zip ici
http://files.spip.org/spip-zone/memoization.zip
je n'ai pas pris le temps de le documenter correctement ; mais il
marche bien et je l'utilise partout : à mon sens il va venir à terme
s'intégrer au core
-- Fil
Suite à la découverte du "cache fou" qui s'emballe, j'ai entammé une course à contre courant qui consiste à demander à mon client FTP d'effacer les fichiers du cache en espérant que ce sera plus rapide que la création simultannée des nouveaux fichiers...
Je pensais à peu près maîtriser la bête puisque au bout de 2h à peu près de vidage, j'avais dégraissé le cache de 400 Mo sur 800 Mo
Suite à je ne sais pas trop quoi, Transmit ayant planté, j'ai relancé la manip pour m'apercevoir que 100 Mo de fichiers venaient d'être réécris (en l'espace que trois fois rien de temps...)
Je m'interroge sur la manière la plus pertinente et la plus efficace pour enrayer les choses ?
> solution 1 : activer "en travaux 2" ?
> solution 2 : solution plus brutale : bloquer tout accès en renommant spip.php le temps de pouvoir vider à fond tmp/cache ?
A la lumière de vos expériences, que me conseilleriez-vous pour enrayer cet emballement qui ne paraît pas très simple à contrôler ?
avec mes 6go je m'en suis bien sorti avec ecrire/?exec=admin_vider
bon faut pomper un peu mais par tranches de +-500mo ça le fait
+memoization et tu pourras à nouveau partir en weekend peinard
L'hémorragie est stoppée... cool !
Maintenant, faire le point et améliorer ce qu'il est possible de faire:
1> memoization installé et activé. OK
2> Quid de la balise #CACHE des squelettes : du fait de la présence de memoization, son emploi est-il le même ? utile ou pas utile ? y a-t-il "conflit" entre les deux ? Bref, y a-t-il qqchose à changer de ce côté-là maintenant que le plugin est activé ?
Des préconisations ?
PS : les données du site : SPIP 2.0.11 - 1600 visiteurs uniques/jour - 60 000 pages/jours - 2 Go de traffic / jour
Merci encore pour tout,
Manu
Bonjour,
Hier j'ai donc vidé à fond le cache de mon site
puis installé memoization
...
Ce matin, je vais jeter un coup d'oeil: aaaaarrrrrrgggh ! Je suis déja repassé à 300 Mo de cache !
Que peut-il donc se passer à votre avis ?
Merci d'avance de vos conseils,
Manu
Bonjour,
as tu pris le soin de lire le fil de discussion depuis le début ? La réponse y figure depuis plusieurs jours, et c'est pourquoi je ne l'ai pas reformulé de nouveau alors que tu as reposé plusieurs fois la même question...
En particulier, je mentionnais le problème du nombre d'url très grand qui découle de paginations croisées, ou infinie en cas de bug sur ton squelette (genre &=>&=>&... sur une url) qui sont toutes parsée par les moteurs de recherche et provoque la mise en cache démentielle que tu rencontres.
L'écran de sécurité de SPIP permet de se protéger contre le parcours par les robots des paginations croisées. Et en ce qui concerne un bug éventuel dans ton squelette, il faut que tu regardes.
Cédric
Merci de ta réponse.
C'est un site sur lequel il y a effectivement pas mal d'url du type ?rubriquexx¶m1=a¶m2=b&debut_pagination1=i&debut_pagination2=j...
Les pages comportent en effet souvent plusieurs blocs proposant des liens thématiques sous forme de listes paginées établies dynamiquement en fonction du contexte (= liens du type "sur le même sujet").
Du coup, quel principes faut-il retenir dans la construction des squelettes pour éviter ces débordements ? Je n'imagine en effet pas renoncer à la présence de ces listes paginées : c'est l'essence même du site !
J'avoue ne pas très bien voir comment modifier les choses...
Manu
Merci de ta réponse.
C’est un site sur lequel il y a effectivement pas mal d’url du type ?rubriquexx¶m1=a¶m2=b&debut_pagination1=i&debut_pagination2=j…
Les pages comportent en effet souvent plusieurs blocs proposant des liens thématiques sous forme de listes paginées établies dynamiquement en fonction du contexte (= liens du type « sur le même sujet »).
Du coup, quel principes faut-il retenir dans la construction des squelettes pour éviter ces débordements ? Je n’imagine en effet pas renoncer à la présence de ces listes paginées : c’est l’essence même du site !
Encore une fois, ma réponse est déjà là :
L’écran de sécurité de SPIP permet de se protéger contre le parcours par les robots des paginations croisées.
Cédric
En détail :
http://www.spip.net/fr_article4200.html