Si je clique sur Sauvegarder la base (ce que je viens de refaire) , je ne peux pas choisir les tables, il attaque directement là :
Sauvegarde (31)
28. spip_referers_articles 76800 77200
Message reçu ce soir :
j'ai voulu faire une sauvegarde de la base avec les stats. Mal m'en a pris, ça a tourné pendant des heures. J'ai fini par abandonner. Un truc bizarre quand même, c'est que le processus de sauvegarde semble tourner en boucle. Je veux dire que j'ai vu la sauvegarde des tables rubriques articles auteurs au moins deux ou trois fois. Après, ça mouline sec sur les referers (normal il y en a 3 tonnes), mais je me demandais du coup si il n'y avait pas des timeout et si spip n'essaie pas désespérément (et infiniment) de faire une sauvegarde...
Ces deux messages proviennent de deux sites différents (que
j'héberge), et de deux webmestres différents. Les deux sites sont gros
et anciens (donc, beaucoup de stats). Il y a probablement quelque
chose à revoir du côté des sauvegardes...
Si je clique sur Sauvegarder la base (ce que je viens de refaire) , je ne peux pas choisir les tables, il attaque directement là :
Sauvegarde (31)
28. spip_referers_articles 76800 77200
les referers et les stats ne sont pas censées être sélectionnées dans la sauvegarde.
Message reçu ce soir :
j'ai voulu faire une sauvegarde de la base avec les stats. Mal m'en a pris, ça a tourné pendant des heures. J'ai fini par abandonner. Un truc bizarre quand même, c'est que le processus de sauvegarde semble tourner en boucle. Je veux dire que j'ai vu la sauvegarde des tables rubriques articles auteurs au moins deux ou trois fois.
C'est manifestement anormal aussi.
Après, ça mouline sec sur les referers (normal il y en a 3 tonnes), mais je me demandais du coup si il n'y avait pas des timeout et si spip n'essaie pas désespérément (et infiniment) de faire une sauvegarde...
Ces deux messages proviennent de deux sites différents (que
j'héberge), et de deux webmestres différents. Les deux sites sont gros
et anciens (donc, beaucoup de stats). Il y a probablement quelque
chose à revoir du côté des sauvegardes...
Ces deux messages proviennent de deux sites différents (que
j'héberge), et de deux webmestres différents. Les deux sites sont gros
et anciens (donc, beaucoup de stats). Il y a probablement quelque
chose à revoir du côté des sauvegardes...
Je remarquais justement hier soir sur un site assez ancien et très
visité dont je m'occupe que les stats prennent une place monstrueuse
(surtout les referers) soit 115Mo des 150Mo de la base ! C'est énorme
!
Est-ce que des tables aussi boudinées n'ont pas une influence sur les
performances du serveur SQL ?
Sans parler des problématiques de la sauvegarde (pas de sauvegarde par
l'espace privé de ces tabes dans ce SPIP 1.9.2, mais par phpmyadmin)
Sans parler des problématiques de la sauvegarde (pas de sauvegarde par
l'espace privé de ces tabes dans ce SPIP 1.9.2, mais par phpmyadmin)
Quand on ne se prend pas un timeout sous phpmyadmin. Et avec des bases
de plusieurs centaines de mégas, on peux y passer sa journée pour faire
un simple transfert vers un autre serveur.
Est-ce qu'une solution ne serait pas de permettre de passer à un mode
plus léger pour les statistiques ?
Par exemple, ne garder des statistiques complètes que pour le mois
précédent et de se contenter que du nombre de visites par articles pour
ce qui précède ?
Sans parler des problématiques de la sauvegarde (pas de sauvegarde par
l'espace privé de ces tabes dans ce SPIP 1.9.2, mais par phpmyadmin)
Quand on ne se prend pas un timeout sous phpmyadmin. Et avec des bases
de plusieurs centaines de mégas, on peux y passer sa journée pour faire
un simple transfert vers un autre serveur.
Il y a scripts php pour les grosses sauvegardes et restaurations :
bigdump par exemple marche très bien.
Quand on ne se prend pas un timeout sous phpmyadmin. Et avec des bases
de plusieurs centaines de mégas, on peux y passer sa journée pour faire
un simple transfert vers un autre serveur.
Est-ce qu'une solution ne serait pas de permettre de passer à un mode
plus léger pour les statistiques ?
Par exemple, ne garder des statistiques complètes que pour le mois
précédent et de se contenter que du nombre de visites par articles pour
ce qui précède ?
Comme je l'indiquais, SPIP ne sauvegarde pas les tables des stats, ni
referers, par défaut.
Peut-être le problème n'est pas vraiment là mais plutôt dans le fait que
des sites forts actifs et anciens ont des bases de données qui peuvent
devenir ultra-volumineuses et donc difficile à exploiter. Et ça peux
être vraiment galère de transférer les données.
Et perdre complètement les données de stats, de referers n'est pas
souhaitable ...
Il faut espérer que de tels sites acceptent de payer un hébergement qui donne accès à des outils de backup plus performants.
On a rien sans rien, et ce n'est pas SPIP qui va transformer une citrouille en carrosse.
Le backup de SPIP est prévu pour fonctionner de manière satisfaisante en général.
A l'epoque de la 1.9 lorsque j'avais tout réécrit, j'avais testé des backups de spip-contrib (alors hebergé en mutu sur ouvaton) avec succès, même si cela prenait plusieurs dizaines de minutes, ça fonctionnait.
Je crois que depuis la fonctionnalité s'est dégradé et les reprises en cours sur les grosses tables-petits hebergements n'est pas satisfaisante.
Cela dit, et pour conclure, fil proposait de passer la sauvegarde en plugin, ce qui permettrait :
- de remettre au carré une sauvegarde simple et robuste, qui ne cherche pas à en faire plus (au contraire de la fonction actuelle qui a été enrichie)
- de faire des variantes basées sur mysqldump, sqlite, ou tout autre outil
(il va de soi que le même plugin doit gérer sauvegarde ET restauration !)
Cela dit, et pour conclure, fil proposait de passer la sauvegarde en plugin, ce qui permettrait :
de remettre au carré une sauvegarde simple et robuste, qui ne cherche pas à en faire plus (au contraire de la fonction actuelle qui a été enrichie)
de faire des variantes basées sur mysqldump, sqlite, ou tout autre outil
(il va de soi que le même plugin doit gérer sauvegarde ET restauration !)
Oui, et peut-être en même temps prévoir une réflexion plus large afin de tirer profit de plugins déjà existant comme Saveauto et Mes fichiers 2 afin de définir une architecture avec un core et des extensions comme la programmation des sauvegardes, la sauvegarde des données hors base…
Je suis justement un pauvre fonctionnaire à qui on demande tous les
jours de transformer les citrouilles en carrosses, en plus de son
travail normal...
Alors j'avais rêvé que SPIP m'y aiderait en me permettant de gérer ces
tables adipeuses sur un serveur neurasthénique avec un site à haute
fréquentation !!
Je trouve que l'idée de Yohann d'en éliminer automatiquement une
partie intéressante...
En attendant, c'est vrai que je ne vois pas trop quoi faire... Mais ça
c'est plutôt pour spip-user...
On Miércoles 30 Septiembre 2009 13:07:04 MARNE Bertrand escribió:
En attendant, c'est vrai que je ne vois pas trop quoi faire...
Je me souviens (mais ça fait déjà quelques années) que AWStats, une fois qu'il
a interprété une portion d'un fichier de log (Apache ou autre), les intègre
dans ses comptes et n'en a plus besoin, ce qui donne une base de taille fixe et
la possibilité d'éliminer les anciens logs au fur et à mesure. Peut-être qu'il
est possible de s'inspirer de ça pour les stats de SPIP, ou bien pour toi
Bertrand, en tant que webmestre, d'utiliser simplement AWStats ou un outil
similaire ? Il est peut-être même possible de générer une entrée utilisable
par AWStats à partir des statistiques collectées par SPIP, ce qui permettrait
de se débarasser de ces dernières une fois intégrées.
> Quand on ne se prend pas un timeout sous phpmyadmin.
Et avec des bases
> de plusieurs centaines de mégas, on peux y passer sa
journée pour faire
> un simple transfert vers un autre serveur.
Il y a scripts php pour les grosses sauvegardes et
restaurations :
bigdump par exemple marche très bien.
de toute façon quand tu en arrive à un site avec une base de données de plusieurs dizaines de Mo il y a forte chance que ton hébergement permette l'accès SSH et donc l'utilisation de mysqldump *nettement* plus adapté/rapide que le dump en php... (et je ne parle même pas des soluces style mysqlhotcopy!)
de toute façon quand tu en arrive à un site avec une base de données de plusieurs dizaines de Mo il y a forte chance que ton hébergement permette l'accès SSH et donc l'utilisation de mysqldump *nettement* plus adapté/rapide que le dump en php... (et je ne parle même pas des soluces style mysqlhotcopy!)
Non, vraiment il faut arrêter de remettre tout sur le dos de
l'hébergement. Spip doit fonctionner de manière parfaite même pour un
site a audience moyenne sur des services d'hébergement associatifs avec
un simple accès phpmyadmin.
Et la réponse ne devrait jamais être qu'il faut payer, avoir un
hébergement ultra-performant, un administrateur système qui maitrise
ssh/sql,..
En fait, mon problème est moins de faire une sauvegarde que
d'améliorer les performances de la gestion de cette base ! Je me
demande si je peux effacer les referers (après sauvegarde sans doute)
sans perdre les reste des infos de stats.
de toute façon quand tu en arrive à un site avec une base de données de plusieurs dizaines de Mo il y a forte chance que ton hébergement permette l'accès SSH et donc l'utilisation de mysqldump *nettement* plus adapté/rapide que le dump en php... (et je ne parle même pas des soluces style mysqlhotcopy!)
Ben non, dans mon contexte administratif, où je ne suis qu'un pauvre
webmestre, je n'ai qu'un accès FTP/phpmyadmin...
Spip doit fonctionner de manière parfaite même pour un
site a audience moyenne sur des services d'hébergement associatifs avec
un simple accès phpmyadmin.
Ce serait vraiment l'idéal c'est sûr ! Mais dans mon cas j'ai bien
conscience que le site est surdimensionné par rapport au serveur (qui
en plus est mutualisé !!!). Mais ce n'est pas pour autant qu'on me
donne les moyens de faire différemment.
Reste le sujet principal: comment alléger le fonctionnement des stats
sur un vieux site sous SPIP qui prends de l'embonpoint... Je vais
chercher un peu dès que mon planning s'allège...
Reste le sujet principal: comment alléger le fonctionnement des stats
sur un vieux site sous SPIP qui prends de l'embonpoint... Je vais
chercher un peu dès que mon planning s'allège...
tu peux désactiver la mémorisation des referer
dans les menus de configuration de spip.
JLuc
de toute façon quand tu en arrive à un site avec une base de données de plusieurs dizaines de Mo il y a forte chance que ton hébergement permette l'accès SSH et donc l'utilisation de mysqldump *nettement* plus adapté/rapide que le dump en php... (et je ne parle même pas des soluces style mysqlhotcopy!)
Non, vraiment il faut arrêter de remettre tout sur le dos de
l'hébergement. Spip doit fonctionner de manière parfaite même pour un
site a audience moyenne sur des services d'hébergement associatifs avec
un simple accès phpmyadmin.
hum, si PHP n'a pas assez de memoire ni de temps d'execution pour faire une sauvegarde, je ne vois pas trop ce que Spip peut faire...
Et la réponse ne devrait jamais être qu'il faut payer, avoir un
hébergement ultra-performant, un administrateur système qui maitrise
ssh/sql,..
Dire qu'il faut un minimum de ressources pour sauvegarder une grosse base, ca ne veut pas dire qu'il faut passer sur du payant.
Chez free par exemple, il y a largement assez de ressources.
