Le Freez: chargement d'une page n'aboutit pas. Unable to add the product + baseDir

[web-biz]

Bonjour,

 

Je dois dire que je n'avais jamais vu ce type d'erreur.

Au redémarrage de mon serveur ce matin (tombé sans signe apparent dans les logs), le site que je gère a bien rebooté et s'est bloqué 30 minutes plus tard, avec l'impossibilité de charger les pages. L'animation du navigateur montre qu'il essaie mais en vain.

Le back office est accessible. Le serveur via Plesk est accessible. j'ai également fait le test d'un page html hébergé sur un le même serveur (autre domaine, même IP), je peux confirmer que le serveur tourne.

Correctement ça je ne sais pas encore.

 

J'ai commencé par avoir l'erreur suivante quand j'ai voulu tester d'ajouter un produit au panier.

TECHNICAL ERROR: unable to add the product.

Details: Error thrown: [object XMLHttpRequest]

Text status: error

errorThrown: undefined

Puis quelques clics plus loin, la requête de ma page n'aboutissait pas.

 

J'ai vérifié les logs du serveur et je n'ai rien trouvé d'anormal, le serveur a été mis à jour récemment (21 aout), et tous les signes de vie de l'hebergement sont au verts.

 

Après un redémarrage du serveur pour pouvoir accéder au site, j'ai fait des vérifications d'erreurs sur la console Firebug, et j'y ai trouvé cette nouvelle erreur :

ReferenceError: baseDir is not defined

url: baseDir + 'order.php',

C'est assez étrange comme erreur car si cela venait de PS_BASE_URI je pourrais pas afficher grand chose.

 

Depuis, toutes les heures environ le site se gèle et le seul moyen de le sortir de cette hibernation momentanée, c'est de redémarrer le serveur. C'est juste pas jouable toutes les heures.

 

Si vous avez déjà expérimenter cela, je suis preneur pour les conseils que vous avez.

Le plus étrange est de ne pas avoir d'erreur évidente, car en toute logique si ça vient d'un script php, le time out finit toujours par interromptre le chargement d'une page web.

 

Merci de votre collaboration.

[SiteProjet]

Bonjour.

 

Un cron tâche peut-être ?

Il faudrait voir si le freeze à une période définie ou si c'est anarchique.

 

Dans le second cas je pencherais vers une corruption de la BDD car si cela est du à un reboot de votre serveur il se peut que cela ait eut lieu à un moment critique.

Une restauration de votre BDD avant le soucis permettrait de checker cela.

 

C'est un simple hébergement Web ou un serveur virtuel sur lequel vous avez l'admin? Car il serait intéressant de checker les écritures qui se font dans votre répertoire Presta, de mêmes que celles ayant lieu dans la BDD.

 

Cordialement,

SP.

[web-biz]

J'ai effectivement pensé à un e tâche cron au début, mais j'en ai 3 qui se font à des heures précises, ne coincidant pas avec le site qui freeze.

Par contre la BDD peut être en cause. Ce que je ne comprends pas, c'est pourquoi après un soft reboot le site fonctionne (dans l'hypothèse où la BDD est corrompue).

C'est un serveur dédié OVH simple.

Je vais essayer de basculer le site sur un autre hébergement pour m'affranchir du serveur et de la BDD.

[SiteProjet]

Bonjour.

 

Parfait si c'est un dédié : dans ce cas vous pouvez faire toute la batterie de tests nécessaires et checker vos logs peu avant le freeze.

En effet une corruption de la BDD n'explique pas forcément le fait qu'un reboot corrige temporairement le soucis, sauf si cela est du à une variable erronée qui génère à terme un overflow.

 

En ce qui me concerne je pencherais plutôt pour un soucis avec Apache ou Mysql; surtout si c'est suite à un crash. A moins que d'autres cms soient toujours accessibles pendant que Presta plante.

 

Et pour le fait de tester sur un autre hébergement c'est effectivement le meilleur moyen de savoir si cela vient de votre dédié ou de Presta / de la BDD ou pas...

 

En espérant que ce brainstorming vous soit profitable

 

Cordialement,

SP

[web-biz]

Merci bien pour ces pistes.

Les logs ont été checké et pas de message d'erreur critique.

Cette nuit le serveur est à nouveau tombé et lorsque je tente malgré tout d'accéder au dédié sous Plesk, j'ai :

ERROR: Zend_Db_Adapter_Exception

SQLSTATE[HY000] [1040] Too many connections

 

0: Abstract.php:144

Zend_Db_Adapter_Pdo_Abstract->_connect()

1: Mysql.php:109

Zend_Db_Adapter_Pdo_Mysql->_connect()

2: Abstract.php:459

Zend_Db_Adapter_Abstract->query(string 'SELECT 1', array)

3: Abstract.php:238

Zend_Db_Adapter_Pdo_Abstract->query(string 'SELECT 1')

4: Abstract.php:155

CommonPanel_Application_Abstract::initDbAdapter()

5: Abstract.php:113

CommonPanel_Application_Abstract->_initDbAdapter()

6: Abstract.php:34

CommonPanel_Application_Abstract->run()

7: Abstract.php:19

CommonPanel_Application_Abstract::init()

8: auth.php3:109

 

J'ai bien cru à un problème Apache, mais quand le serveur reste en route, mon site en question est en freezing total, tandis que je peux accéder à un site Wordpress hébergé sur le même serveur.

 

La variable en overflow est une possibilité envisageable. Assez étrange car aucun signe avant mais hé pourquoi pas !

Je vais finir de basculer le site via FTP, c'est assez long et je vais voir.

 

Merci de ton aide.

[SiteProjet]

Bonjour.

 

D'après le log que vous affichez, c'est du à un soucis de configuration. Il faut savoir que Prestashop fait énormément (trop?) de requêtes sql. C'est un chose qui a été considérablement allégée avec la V 1.4.9 (générant des performances augmentées de plus de 300% d'ailleurs parait-il...).

 

Cela n'explique pas qu'avant tout marchait bien et que ce ne soit plus le cas, ou du moins la raison m'échappe.

Quoi qu'il en soit vous pouvez tenter de migrer vers la 1.4.9 ou modifier les paramètres de votre mysql afin d'autoriser d'avantages de requpetes. Cela se fait dans le fichier de conf :

set-variable=max_connections=300

(300 au lieu de 150 par exemple).

[web-biz]

Ca m'a l'air pas mal ce réglage.

C'est une ligne qu'il faut rajouter ?

Je pose la question car je ne la trouve pas dans mes fichiers de config prestashop.

Pour ce site je suis sur une veille version : 1.3.2.3 (et ne souhaite pas en changer). Mais j'ai vérifié sur une version 1.4.8.2, je ne la trouve pas non plus.

J'ai fait un phpinfo sur le serveur pour voir s'il prenait en compte set-variable=max_connections, pas de trace non plus.

J'en déduis qu'il faut l'ajouter et sur quel fichier ?

 

Par ailleurs, j'ai lancé Watchdog sur mon serveur et je vois que l'utilisation de l'UC central fleurte abusivement avec 100%. Ce qui expliquerait à mon sens que le serveur tombe et l'overflow. Pour comparer, d'un autre côté, sur un autre serveur dédié équivalent (sous Plesk aussi, même version 10.4.4) j'ai dupliqué le site en cause et là tout marche correctement. De toute évidence je n'ai pas le même nombre de connections car c'est un nom de domaine inconnu par les internautes. Mais sur cet autre serveur qui abrite 2 sites prestashop (avec celui de test en 1.3.2.3 + un autre en 1.4.8.2), le CPU tourne au max à 20%.

 

Je pense avoir un soucis d'utilisation de CPU sur le serveur en cause. Au vu que les 2 serveurs dédiés équivalents hébergent le même site, je pense à en déduire qu'il y a une interaction inhabituelle avec le premier serveur. J'ai contacté OVH et j'attends un diagnostic matériel.

 

J'aimerais bien essayer set-variable=max_connections si tu peux me dire où le modifier ?

[SiteProjet]

Le max_connexion est une variable système de mysql et non de PHP. Il faut savoir qu'un serveur Linu gère allègrement les plus de 500 connexion simultanées, mais ça dépend aussi de votre RAM.

 

Sous quel OS est ce serveur ?

Avez-vous accès en SSH à la racine, ou au moins en FTP?

 

Dans le premier cas vous pourrez facilement augmenter les max_connections. Le fichier se situe dans le repertoire de mysql, ou dans /etc/my.cnf sous linux.

Il se peut qu'un restart d'apache (service apache2 restart : sous linux) soit nécessaire. Concernant votre UC, vous pouvez facilement voir quel processus prend de la place, mais la commande dépend de votre OS.

[web-biz]

Mon OS est Linux

[web-biz]

SiteProjet, j'ai limité le nombre de connections et la bande-passante sur le serveur via la console de gestion, mais rien n'y a fait. Le problème persiste.

 

J'ai transféré le site de prod sur un autre serveur dédié. Pour le moment tout semble fonctionner. Si sur ce serveur le site fonctionne sans freeze / page gelée, ni le serveur qui tombe, alors je peux mettre en cause le serveur d'origine, sa base de données, ses modules.

Sur le serveur OVH les dysfonctionnements étaient fréquents, je vais vite être fixé.

A suivre donc!

[coeos.pro]

tu as encore ton erreur TECHNICAL ERROR ? elle surviens sur toutes les pages ou alors quand tu ajoutes un produit au panier en ajax ?

[web-biz]

Non, j'ai désactivé l'ajax du panier le 27/08, et je n'ai plus eu l'erreur, cela dit le résultat était identique car la page se figée quand je cliquais sur ajouter au panier. Et parfois juste en navigant de page en page, je pense que l'UC du serveur était déjà en overflow.

[web-biz]

Après 2 jours où le site a été transféré sur un autre serveur dédié, il fonctionne à nouveau normalement. Plus de page gélée/freeze ou de crash serveur. J'en conclus qu'il y a une incidence évidente à propos du serveur d'origine OVH, celui qui causait des problèmes répétitifs. Cela dit je ne suis pas sûr de détenir la vérité, mais je penche pour un problème du serveur apache ou MySQL d'OVH.

Un diagnostic poussé doit être réalisé par le service technique d'OVH pour détailler d'avantage ce problème.

 

SiteProject, si tu as la commande sous la main pour voir quel processus prend de la place sur l'UC, je suis preneur. Merci de ton aide.

[web-biz]

Bon ça marche mais je dois avoir une corruption partielle de ma base de donées, car je vien s de m'apercevoir que je n'ai pas accès à l'onglet Clients>Paniers dans mon backk-office. Voir le post que j'ai ouvert sur cette erreur

[SiteProjet]

Après 2 jours où le site a été transféré sur un autre serveur dédié, il fonctionne à nouveau normalement. Plus de page gélée/freeze ou de crash serveur. J'en conclus qu'il y a une incidence évidente à propos du serveur d'origine OVH, celui qui causait des problèmes répétitifs. Cela dit je ne suis pas sûr de détenir la vérité, mais je penche pour un problème du serveur apache ou MySQL d'OVH.

Un diagnostic poussé doit être réalisé par le service technique d'OVH pour détailler d'avantage ce problème.

 

SiteProject, si tu as la commande sous la main pour voir quel processus prend de la place sur l'UC, je suis preneur. Merci de ton aide.

 

 

Bonjour.

 

Désolé pour la réponse tardive.

Concernant les max-connexion, il s'agissait bien évidemment d'augmenter leur nombre et non de le diminuer!

 

Pour ce qui est de la commande permettant d'afficher les processus, l'utilisation de l'UC et diverses autres infos, cela dépend de votre distribution.

Vous pouvez déjà utiliser les commandes "loadaverage" et "ps" (avec un "man"), ainsi que "top".

 

 

Cordialement,

SP.