smiledeco Posted September 17, 2015 Share Posted September 17, 2015 Bonjour Je suis en version 1.6.0.14 avec un hébergement mutualisé Perf.1 chez OVH. Mon site est tombé il y a 1 h et j'ai donc contacté la hotline d'OVH... Ils ont bien constaté qu'il y avait un pb chez eux... Un ticket a donc été ouvert. 15 minutes après, je reçois un mail qui me dit que tout est OK mais que désormais le site affiche de manière aléatoire un joli "Link to database cannot be established : SQL STATE [08004] [1040] too many connections" Et, en gros, le problème est désormais de votre côté !!! Sympa chez OVH, non ? Bref, je me retrouve avec trop de connexions simultanées à ma base de données (MySQL). Ce n'est pas systématique mais c'est quand même pénible... Avant d'imaginer un changement d'hébergement (VPS Cloud ou dédié), je souhaiterai avoir votre avis et bénéficier de vos conseils sur le problème bdd. Comment diagnostiquer cela ? Comment identifier les requêtes restées ouvertes sur la bdd ? Comment les fermer (sans risques) ? Je suis dispo en mp si besoin. Merci de votre aide. JL 1 Link to comment Share on other sites More sharing options...
Alex--77 Posted September 17, 2015 Share Posted September 17, 2015 Bonjour, Perso, j'utilise OVH comme hébergement et lorsque je prends un hébergement mutualisé pour un prestashop, je prends performance 2. Au moment ou l'erreur apparait faut voir qu'elle action a été faite chargement d'une page produit, n’importe quel page, ... Ensuite voir dans le manager OVH ou les logs s'il y a eu beaucoup de connexion client, dans ce cas la faudrait passer au perf 2. Peut-être que ça vient d'un module, qui tourne en boucle. Pour voir si c'est un module faut les désactiver un à un et voir si le problème revient. Link to comment Share on other sites More sharing options...
smiledeco Posted September 17, 2015 Author Share Posted September 17, 2015 Bonjour Alex Merci pour ta réponse. A priori, performance 1 ou 2 ne change rien au nombre de connexions simultanées sur la bdd. C'est max 30 chez OVH en mutualisé. En revanche, je soupçonne quand même un problème sur des requêtes non fermées, sûrement dû à un module qui dysfonctionne. Je n'ai pas vraiment envie de les désactiver 1 à 1, d'autant plus que le dysfonctionnement est aléatoire. Je vais regarder les logs d'OVH... D'autres avis ? conseils ? Link to comment Share on other sites More sharing options...
prestasafe Posted September 17, 2015 Share Posted September 17, 2015 Bonjour, il faudrait consulter les logs serveurs et regarder sur quelle adresse on lieux les connexions douteuse et bannir les ips. je vous conseille de supprimer les modules qui ne vous servent pas du tout et surtout de regarder au niveau des vieux modules (si votre boutique date depuis en moment) Cordialement Link to comment Share on other sites More sharing options...
S0DA Posted November 7, 2016 Share Posted November 7, 2016 Bonjour, Une suite ?Le problème a t'il été résolu ? J'ai exactement le même problème .... Link to comment Share on other sites More sharing options...
ezcb Posted November 22, 2016 Share Posted November 22, 2016 Bonjour, Le problème c'est MySQL qui s'engorge et explose, Le problème démarre avec les requêtes du bock de recherche du site, les requêtes s'empilent et font monter le serveur en température. Ajoutez un pic de trafic + le passage du bot de google et c'est le crash assuré. Pour ma part serveur dédie 8 cœurs et MYSQL à 800%. Premièrement il faut retrouver un site fonctionnel (pour vos clients et votre Référencement) donc on va provisoirement demander a google d'espacer de quelques secondes ses requêtes pour éviter le crash. Donc rendez vous sur Google webmastertools allez dans paramètre du site et cliquez sur Limiter la vitesse d'exploration maximale de Google Pour ma part j'ai modifié la vitesse d'exploration à 24 demandes par seconde et 4 secondes entre les demandes. Sachez que votre modification est provisoire, google réinitialise les réglages tous les 90 jours. Bon maintenant on va corriger le problème des requêtes qui s'empilent et en corrigeant cela on va gagner en performance et de manière très significative (recherche instantanée et site beaucoup plus rapide). Comme on sait que ce sont les requêtes de recherche qui consomment toutes les ressources Mysql on va simplement faire un SQL_NO_CACHE sur celles ci. Privilégiez l'override: Sur prestashop 1.6.1.7 récupérez le fichier search.ph dans le dossier Classes. Nous allons modifier la fonction FIND (public static function find) Remplacez la ligne 178 $db = Db::getInstance(_PS_USE_SQL_SLAVE_); Par $db = Db::getInstance(_PS_USE_SQL_SLAVE_); $no_database_cache = false; Ensuite on modifie la requête a la ligne environ 202 $intersect_array[] = 'SELECT si.id_product FROM '._DB_PREFIX_.'search_word sw LEFT JOIN '._DB_PREFIX_.'search_index si ON sw.id_word = si.id_word WHERE sw.id_lang = '.(int)$id_lang.' AND sw.id_shop = '.$context->shop->id.' AND sw.word LIKE '.($word[0] == '-' ? ' \''.$start_search.pSQL(Tools::substr($word, 1, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' : ' \''.$start_search.pSQL(Tools::substr($word, 0, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' ); Par $intersect_array[] = 'SELECT '.($no_database_cache?'SQL_NO_CACHE ':'').'si.id_product FROM '._DB_PREFIX_.'search_word sw LEFT JOIN '._DB_PREFIX_.'search_index si ON sw.id_word = si.id_word WHERE sw.id_lang = '.(int)$id_lang.' AND sw.id_shop = '.$context->shop->id.' AND sw.word LIKE '.($word[0] == '-' ? ' \''.$start_search.pSQL(Tools::substr($word, 1, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' : ' \''.$start_search.pSQL(Tools::substr($word, 0, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' ); Idem pour la requête a la ligne 286 on remplace if ($ajax) { $sql = 'SELECT DISTINCT p.id_product, pl.name pname, cl.name cname, cl.link_rewrite crewrite, pl.link_rewrite prewrite '.$score.' FROM '._DB_PREFIX_.'product p INNER JOIN `'._DB_PREFIX_.'product_lang` pl ON ( p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('pl').' ) '.Shop::addSqlAssociation('product', 'p').' INNER JOIN `'._DB_PREFIX_.'category_lang` cl ON ( product_shop.`id_category_default` = cl.`id_category` AND cl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('cl').' ) WHERE p.`id_product` '.$product_pool.' ORDER BY position DESC LIMIT 10'; return $db->executeS($sql, true, false); } Par if ($ajax) { $sql = 'SELECT DISTINCT '.($no_database_cache?'SQL_NO_CACHE ':'').' p.id_product, pl.name pname, cl.name cname, cl.link_rewrite crewrite, pl.link_rewrite prewrite '.$score.' FROM '._DB_PREFIX_.'product p INNER JOIN `'._DB_PREFIX_.'product_lang` pl ON ( p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('pl').' ) '.Shop::addSqlAssociation('product', 'p').' INNER JOIN `'._DB_PREFIX_.'category_lang` cl ON ( product_shop.`id_category_default` = cl.`id_category` AND cl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('cl').' ) WHERE p.`id_product` '.$product_pool.' ORDER BY position DESC LIMIT 10'; return $db->executeS($sql, true, false); } et enfin on remplace a la 314 $sql = 'SELECT p.*, product_shop.*, stock.out_of_stock, IFNULL(stock.quantity, 0) as quantity, Par $sql = 'SELECT '.($no_database_cache?'SQL_NO_CACHE ':'').' p.*, product_shop.*, stock.out_of_stock, IFNULL(stock.quantity, 0) as quantity, Enregistrez et savourez le resultat. N’hésitez pas non plus a mettre un Crawl delay 10 sur votre robots.tx. Autre chose pour les grosses boutique n’hésitez pas non plus a désactiver vos modules de cache tel que cachemanager et de comparer vos perf avec et sans module. en effet nous concernant depuis quelque temps notre serveur met moins de temps a exécuter les requêtes qu'a lire le cache. En espérant vous avoir aidé. Cdt EZ 2 Link to comment Share on other sites More sharing options...
S0DA Posted November 22, 2016 Share Posted November 22, 2016 Merci pour les conseils ezcb Je vais tester ça et je vous tiens informé Link to comment Share on other sites More sharing options...
Cedric Prieels Posted December 5, 2016 Share Posted December 5, 2016 et résultat ??? car j'ai le même problème ! Link to comment Share on other sites More sharing options...
lepaps Posted December 5, 2016 Share Posted December 5, 2016 J'ai ce probleme en ce moment sur mon site avec un OVH mutualisé, vous avez la meme ? Link to comment Share on other sites More sharing options...
Cedric Prieels Posted December 5, 2016 Share Posted December 5, 2016 oui site inaccessible sur ovh mutualisé également Link to comment Share on other sites More sharing options...
lepaps Posted December 5, 2016 Share Posted December 5, 2016 ok ça doit etre global car je surfais sur un autre site et j ai eu aussi le probleme xD Link to comment Share on other sites More sharing options...
kamppa Posted January 3, 2017 Share Posted January 3, 2017 (edited) I did what is written in post #6 but I get this error when editing products in catalog: Parse error: syntax error, unexpected 'No_database_cache' (T_STRING), expecting variable (T_VARIABLE) or '$' in /home/yourshop/www/classes/Search.php on line 179 Edit: Nevermind! There were some additional spaces in my code. I don't know where they came from but it is fine now. Thanks for the tip! Edit2: I get the following error when using search with this code: Notice: Undefined variable: no_database_cache in /home/yourshop/www/classes/Search.php on line 203 Notice: Undefined variable: no_database_cache in /home/yourshop/www/classes/Search.php on line 315 Edited January 5, 2017 by kamppa (see edit history) Link to comment Share on other sites More sharing options...
zeltron2k3 Posted February 17, 2017 Share Posted February 17, 2017 bonjour, merci pour ce tuto ezcb , je suis chez OVH, problème résolue. cordialement. ZelTroN-2k3 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now