Site Officiel
En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".
Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact
De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.
Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".
Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.
Submitted by webmestre on
Bonjour,
encore des soucis me mémoire allouée insuffisante pour exécuter les requêtes => gros plantage en live.
Est-il possible et souhaitable de vider manuellement les tables de cache de la BDD ?
Si oui, quelles tables ?
Par avance, merci : grosse panade.
Salut, Je ne pense pas qu’il
Permalien Soumis par drupalfrance le 15 Novembre, 2010 - 15:04
Salut,
Je ne pense pas qu'il y ait un rapport évident entre la taille de ta BDD et la mémoire vive consommée pour exécuter Drupal (ta base de données n'est pas chargée intégralement dans la mémoire à chaque affichage de page).
Si tu veux effacer le cache manuellement, il faut vider toutes les tables dont le nom commence par "cache".
Merci de cette info. J’étais
Permalien Soumis par webmestre le 15 Novembre, 2010 - 17:33
Merci de cette info.
J'étais en mutualisé chez OVH. Le site a migré en dédié : c'est le jour et la nuit, en terme de vitesse d'accès.
Il me semble toutefois que Drupal est un peu gourmand de ressources : Ram pour les scripts PHP, taille de BDD, mémoire BDD...
Pour info, un site avec <100 membres a atteint 115 Mo de RAM dans la BDD sur un serveur SQL privé chez OVH.
Puis la taille de certaines requêtes a effondré la RAM du mutualisé.
Mais je persiste à utiliser cet outil parmi les plus évolués que j'ai jamais manipulés.
Et je généralise son déploiement pour d'autres besoins.
Pour moi Drupal n’est en
Permalien Soumis par emerya le 15 Novembre, 2010 - 19:21
Pour moi Drupal n'est en effet pas adapté pour du mutualisé, sauf dans des versions vraiment réduites.
Après, se pose la question de la gestion du cache de Drupal avec les modules associé (boost en anonyme par ex. et memcache + authcache pour les utilisateurs connectés).
Sur dédié ou virtual host,
Permalien Soumis par webmestre le 15 Novembre, 2010 - 21:40
Sur dédié ou virtual host, des gains de performance sont immédiatement visibles. Le site en question n'est pas un blog, mais un portail pour 5-10 000 abonnés / 1000 - 2500 v. uniques/jour
Drupal est très consommateur
Permalien Soumis par vincent59 le 16 Novembre, 2010 - 11:43
Drupal est très consommateur de ressources bases de données, c'est à mon avis un des points les plus critiques à améliorer (et à surveiller).
En dédié, l'idéal est d'avoir une taille de buffer suffisamment élevée pour tout monter en mémoire ou presque.
Et désactiver la journalisation des accès si tu n'as pas besoin de traces, ça consomme pas mal d'écritures sur disque
«Et désactiver la
Permalien Soumis par webmestre le 16 Novembre, 2010 - 14:27
"Et désactiver la journalisation des accès si tu n’as pas besoin de traces, ça consomme pas mal d’écritures sur disque"
Ou bien les récupérer pour les traiter en local sans les garder trop longtemps dans la bdd, peut-être ?