1and1 bloque mysql : trop de requètes ,trop de fréquentations...., 1and1 bloque mysql : trop de requètes ,trop de fréquentations.... Options

[lelus]

Bonjour à tous,

je viens de recevoir un gentil m@il de 1and1 qui est mon hébergeur depuis près de 3ans pour me dire que depuis 24h ils ont bloqués mon accès à ma base de donnée mysql sans aucune alerte et sans aucune mise en garde ...

mise à part ma folle envie de les incendier au sens propre du therme voici donc se fameux message :


Monsieur xxxxxx, Je me permets de vous contacter à la demande de mes collègues sysadminss'occupant de nos serveurs SQL.
Ces derniers ont constatés après plusieurs emails de clients signifiantsdes lenteurs que votre base se trouve parmi les bases responsables deces lenteurs. Cette alerte concerne votre compte client xxxxxxx Voici un log relevé par mes collègues :

DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:00:53'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:00'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:07'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:13'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:20'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:25'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:32'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:38'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:44'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:50'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:01:55'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:00'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:06'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:11'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:19'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:23'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:26'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:27'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:27'
DELETE FROM cache WHERE cache_expires <= '2008-05-08 17:02:30'

Une telle utilisation se trouve trop importante pour un serveur SQLmutualisé. (pkoi on pais alors...)

Dans cette urgence, mes collègues furent contraints de suspendre cettebase de données.Nous sommes convaincus que vous comprendrez notre décision afin degarantir un servir équitable pour l'ensemble de nos clients se trouvantsur la même installation que vous.

Une mise à jour des scripts et une indexation de la base ont trèssouvent raisons de ces lenteurs.

Nous comptons sur vous pour la régularisation rapide de votre problème,faut de quoi mes collègues seront contraints de supprimer définitivement la base de données.

bref que de bonheur après une journée de travail d'apprendre qu'on ruine votre entreprise sans aucun avertissements ...

Voilà donc le problème viens bien du cache et de la mise en place de mes pages via le cache pour accélérer l'ouverture du site (enfin je crois)

si quelqu'un pourrait m'aider en me confirmant si je dois réelement désactiver le cache via mon site auquel je n'ai bien sur plus accès

ou modifier carrément une installation déjà existante.

lors de la conception j'avais fais le tour des contributions via la liste créez par les utilisateur de oscommerce-fr et avais donc comme conseillé dans les faq de tout faire pour optimiser la vitesse d'ouverture du site ...


merci d'avances pour toutes aides ou toutes réponses

si cela est déjà arriver a certains d'entre vous merci de me contacter via mp ou directement sur se post

afin de ne pas laisser 1and1 s'en tirer à si bon compte car cette façon de faire inaccéptable

Ce message a été modifié par lelus - 9 May 2008, 17:39.

[regne]

Salut,

Si il te coupe c'est que ta base de données doit etre vraiment enorme...

Tu n'as pas pensé a passer sur un serveur dédié?

[delete]

Tu as vérifiés la taille de ta tes tables avec phpmyadmin notamment sessions ?

si elle est trop grosse ne te gène pas à la vider ...

[lelus]

si et cela ne devrait pas trop tarder
ben se n'est pas mon plus gros site en base de donnée mais en fréquentation

je viens de retrouver une des contributions installés (mais un gros doute me turlupine)

est-il possible que se soit généré par thumbnail ?

http://www.oscommerce-fr.info/forum/index....howtopic=21066/ (un générateur automatique de vignettes avec gestion de cache)

je me souviens l'avoir installé

mais j'ai plus aucun accès à ma base de donnée et n'ai aucun accès au site ou à son administration ^^ vive 1and1

Ce message a été modifié par lelus - 9 May 2008, 16:41.

[regne]

J'utilise thumbnail sans aucun souci et je crois bien qu'il ne touche pas a la bdd, il crée juste des images miniature...

Tu les a apelé ?

Il sont ouvert aujourd'hui je les ai eu ce matin

Ce message a été modifié par regne - 9 May 2008, 16:51.

[lelus]

voilà donc je les ai appelé et voilà donc ma situation

l'erreure n'en est en faite pas une ...

il semblerait que mon site subissent un accès trop important et de 12 à 13 000 requètes bref il m'oblige à prendre un serveur privé ....

je tenais tout de même à préciser que se compte etait un compte offert pour une durée de 3 ans

ma base de donnée utilise 1.6mo sur 100 disponible ... et niveau espace ftp j'en utilise même pas un dixième ...

donc voilà avis à tout ceux qui dispose de ces fameux comptes vous voilà mis au parfum.

bref je ne rage pas contre le fait de me transférer vers un serveurs privé et de payer un peu plus que mes 5 noms de domaines mais je trouve quand même

malheureux de bloqué les gens sur le fait accomplis avant un long week-end de 3 jours ou mon site marchand ne réalisera aucun chiffre d'affaire tant qu'il ne me

l'auront pas débloqué ....



bref j'édite le nom du post

et invite tout ceux qui ont eu ou auront se genres de mésaventures à en faire part pour partager notre expèrience et en savoir un peu plus sur les méthodes de ces lascars...

Ce message a été modifié par lelus - 9 May 2008, 17:41.

[salva]

Bonjour,

En fait je pense que si tu relis le contrat qui te lie à 1and1 sa doit être écrit en tout petit les quotas de requetes, de hits, de % de mémoire utilisée auquels tu as droit.

C'est comme cela pour tout les hébergements mutualisés.
Ce qui n'est pas normale effectivement c'est qu'il coupe sans prévenir.

Mais ils ont déjà la réponse à cette question. Tu es l'administrateur de ton compte (Base et Http) donc tu dois en surveiller
le bon fonctionnement dans les limites du système.

Bon, ben je crois que je vais aller voir mes Logs

@+

[nico1075]

bonjour as tous

je trouve que la façons de procéder de 1&1 sur un weekend de 3 jours est frabchement déplorable.
c est sur ce genre de w e que l on peut réaliser du chiffre et la c' est limite si ils ne plombe pas ton affaire .
perso chez alwaysdata ils ne m ont jamais fais ca meme si je dépasse un peu . (bien que la bande passante est illimitée.)


enfin triste méthode quand mème et surtout pas très loyale

Ce message a été modifié par nico1075 - 11 May 2008, 17:18.

[paton]

Bonjour
Nous ils nous ont fait le coup : trop de requetes avec des fichiers logs inexploitables.
Donc nous sommes allés ailleurs en vds (sivit), plus de souci et plus de rapidité.
Cordialement

[NoZic]

Bonjour,

Sinon je me demandais là, pourquoi stocker en BDD ce qui peut l'être en fichier dans un répertoire de cache bien configuré ??
OsC le fait très bien...

Non parce que même sans parler de mutualisé ni de charges serveur etc..., il est tout de même plus logique de le faire en fichier, c'est plus rapide de lire dans un fichier que de faire une requête dans une base conséquente, non ?? (je peux dire une connerie, mais d'un point de vue logique ça se tient sachant que les données de la base sont dans un fichier...)

[azuranet]

Bonjour,

Sinon je me demandais là, pourquoi stocker en BDD ce qui peut l'être en fichier dans un répertoire de cache bien configuré ??
OsC le fait très bien...

Non parce que même sans parler de mutualisé ni de charges serveur etc..., il est tout de même plus logique de le faire en fichier, c'est plus rapide de lire dans un fichier que de faire une requête dans une base conséquente, non ?? (je peux dire une connerie, mais d'un point de vue logique ça se tient sachant que les données de la base sont dans un fichier...)

Bonjour,

En fait non, c'est tout l'inverse

D'abord, il faut savoir que la plupart des hébergeurs mutualisés s'appuient sur une architecture distribuée. Par conséquent les fichiers ne se trouvent pas sur le(s) serveur(s) HTTP mais sur un serveur de fichiers utilisant NFS. Autrement dit, chaque fonction sur le système de fichier se traduit par un appel NFS qui est bien plus coûteux en ressources (et bien moins performant !) qu'une requête envoyée à un SGBD.

Au delà de cette considération, il faut se rappeler que les SGBD ont été précisément conçus pour optimiser le stockage et l'accès aux données. Vous pouvez donc être certain que le SGBD sera toujours plus efficace que n'importe laquelle des structures de fichier mises en place.

[delete]

@gentag
@azuranet

Un filesystem est une base de données !

Si tu fais un cache (eg: /tmp) en ramdisk tu auras de meilleures performances qu'avec une BDD !

Enfin le topic initial ce n'était pas trop ça, il faut vérifier la taille des tables afin d'éliminer les données stockées depuis des lustres (eg: session)

[azuranet]

Si tu fais un cache (eg: /tmp) en ramdisk tu auras de meilleures performances qu'avec une BDD !

Oui s'il n'y a qu'un ID de session à stocker, encore qu'avec le moteur Memory HEAP implémenté par MySQL, on doit obtenir des résultats très proches. Seulement voilà, impossible de monter une partition sur un mutualisé.

Enfin le topic initial ce n'était pas trop ça, il faut vérifier la taille des tables afin d'éliminer les données stockées depuis des lustres (eg: session)

C'est effectivement le coeur du problème, il y a beaucoup d'utilisateurs qui ne se soucient jamais de vider la table de sessions. La table grossit alors indéfiniment jusqu'à ce que l'hébergeur intervienne.

[delete]

C'est effectivement le coeur du problème, il y a beaucoup d'utilisateurs qui ne se soucient jamais de vider la table de sessions. La table grossit alors indéfiniment jusqu'à ce que l'hébergeur intervienne.

Ce n'est pas à l'hébergeur d'intervenir mais à l'hébergé ...

En bref il me semble normal d'optimiser au maximum sa BDD et d'en assurer la maintenance comme ceci : http://www.oscommerce-fr.info/forum/index....st&p=274448 avec un grand merci à AL1

[azuranet]

Si seulement tous les Clients en étaient conscients !

En pratique, beaucoup ne s'en préoccupent jamais. Il est fréquent que l'on retrouve des tables de sessions de quelques centaines de Mo. Nous sommes bien obligés d'intervenir tôt ou tard sous peine de pénaliser les performances du serveur.

[delete]

La moindre des choses c'est de prévenir le client avant

Si tu n'est pas concerné

Si tu es concerné

[azuranet]

Il y a bien sûr la manière de le faire. Certains ne font pas dans la dentelle, d'autres prennent le temps de contacter le Client. Ca fait aussi partie des critères à prendre en compte quand on choisit un hébergeur mutualisé.

[xaglo]

c'est mignon vos discussions éthiques... Néanmoins bien éloigné des questions OsC de là à ce qu'azuranet vienne nous vendre ses solutions d'hébergement, il n'y a qu'un pas.

Pour reprendre le sujet de la discussion en cours, ce soucis avec la table sessions est récurrent, il semble donc bien que quelques versions ont ce défaut!!! Mais je tiens à préciser que ce n'est pas le fonctionnement normal d'OsC

En théorie cette table se vide toute seule. Si vous avez ce défaut, merci d'ouvrir un sujet dans le forum fonctionnement en précisant votre version pour essayer de le résoudre

[thierry_montpell...]

@ XAGLO

Je trouve intéressant la discutions de azuranet et instructive !
Il ne parle pas de proposition d'hébergement mais il vient juste donner un avis et ses connaissances !
C'est un peu le but d'un forum me semble il ?!?

je vais ouvrir un autres post sur le sujet car j'ai ce problème sur une MS2 qui est mise a jour quand il le faut !

Bonne journée à tous
Thierry

[xaglo]

je ne dis pas le contraire... D'ailleurs, le sujet est-il fermé??? J'anticipe juste la dérive inévitable que peut prendre ce genre de discussion quand un prestataire proposant de l'hébergement prend parti

[thierry_montpell...]

On est d'accord

Mais c'est juste que dire qu'on s'éloigne de OSCOMMERCE quand on parle de technique de l'hébergement, c'est dure a entendre.
Car on est obliger d'avoir un hébergement !!!
Pour une fois qu'on a l'avis (effectivement technique) d'un hebergeur qui ne propose pas se service on ne va pas lui demander de partir !

Jamais vu sur ce forum de personne d'OV* ou AM** discuter ici !
Il doivent penser qu'il vont perdre leur temps pas lui !!!

Le sujet de notre discutions est clos pour ma part car ce n'est pas le theme du post

Aller je retourne coder !!!

Thierry