Jump to content

manoaratefy

Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by manoaratefy

  1. Bonjour,

    J'ai un petit souci sur mon site. Quand je vais sur des catégories de produits, le panier dans la position displayNav2 de mon thème disparaît si un produit est déjà sur le panier. Il y a d'autres modules sur cette position qui continuent à s'afficher correctement.

    J'ai vérifié les exceptions dans le back-office > Apparence > Positions mais rien.

    Auriez-vous une idée de la solution ?

    PS : le souci pourrait potentiellement être dû à une récente migration du site qui a été fait, toutefois ce n'est pas très sûr.

  2. Good morning,

    I know the topic is old, but I wanna share how I solved it.

    The reason is that the AUTO_INCREMENT value is too high for the field 'id_product' (int 10).

    You have to check why AUTO_INCREMENT is very high (maybe a wrong id_product) somewhere in the table. Adjust it, and then put the AUTO_INCREMENT value to the lower possible.

  3. 20 hours ago, joseantgv said:

    Peut-il s'agir d'un processus externe qui fait de nombreuses demandes et lance votre boutique ?

    Vérifiez les logs !

    Je viens de revérifier à nouveau les logs PHP-FPM, le slow log PHP-FPM, celui d'Apache, celui de MySQL, rien de remarquable. J'ai activé le mode débogage et j'ai profilé la requête AJAX, aucune erreur affichée sur le profilage (à part quelques soucis de traduction), pourtant, erreur 500.

  4. 20 minutes ago, SPEAZ said:

    Quel est votre hebergeur pour le VPS ? Ce n'est pas un problème de puissance mais peut etre juste le VPS chez votre hebergeur car je fais tourner plein de sites prestashop sous VPS OVH et jamais eu ce probleme 

    Justement, je suis l'hébergeur. Je gère toute la partie hébergement depuis le montage du serveur jusqu'à l'installation du site. Il n'y a (à mon avis) aucune raison que ce souci provient de l'hébergeur. J'ai d'ailleurs d'autres sites Prestashop sur le même VPS qui n'a pas ce souci, et j'ai d'autres sites Prestashop sur d'autres VPS du même serveur physique qui n'ont également pas ce souci.

    Toutefois, pour en avoir le coeur net, j'ai copié le site sur un VPS OVH que j'utilise pour des tests, je l'ai fait tourner cette nuit en interne (pas de visiteurs à part un robot qui check l'état du site tous les 10 secondes), ce matin j'ai eu 5 notifications de coupures à 4h01, 5h05, 6h02, 7h01 et 8h04.

  5. 16 hours ago, SPEAZ said:

    Si en changeant sur un serveur dédié le problème a disparu c'est que c'est un probleme avec le VPS

    J'ai pourtant dupliqué le site sur un autre VPS un peu plus puissant, le problème survient. J'ai réinstallé le même VPS, j'ai mis un Prestashop vierge dessus, pas de souci. Je ne vais quand même pas mettre un dédié de 200 € / mois pour un petit Prestashop de quelques poignées de visiteurs ?

    16 hours ago, joseantgv said:

    Une sauvegarde ?

    Aucune module de sauvegarde installé sur Prestashop et pas de sauvegardes en place du côté du serveur.

  6. Bonjour,

    J'ai un souci avec un site Prestashop. Il rencontre une coupure toutes les heures (16h00, 17h00, 18h00, ...). Le http:// fait un timeout. Ce n'est pas une coupure très longue, mais revient souvent.

    Il n'y a pas de cron job à ma connaissance qui pourrait revenir toutes les heures et qui pourrait causer le souci.

    J'ai dupliqué le site sur un VPS vierge et monitoré, le même souci est toujours là.

    J'ai dupliqué le site sur un serveur dédié vierge (un bi-CPU 20 coeurs à 128 Go de RAM) et fait un nouveau monitoring, le souci a disparu.

    A mon avis, il y a quelque chose qui se passe toutes les heures, et quand ça s'active, ça bloque le chargement. Et avec le gros dédié, la "chose" qui se passe se termine très rapidement, d'où l'absence de coupure.

    Y a-t-il un moyen de connaître "la chose" ?

  7. Bonjour,

    J'ai un petit problème avec un Prestashop sur un VPS. Quand je modifie un produit sur celui-ci, il faut que j'insiste plusieurs fois avant que l'enregistrement soit pris en compte, sinon ça renvoie "Unable to update settings" et une erreur 500 sur l'AJAX.

    J'ai essayé d'activer le mode débogage pour profiler la requête AJAX et trouver l'erreur rencontrée, mais rien. J'ai vérifié les logs d'erreurs PHP, rien. J'ai surveillé le log MySQL, toujours rien. Pourtant, le serveur VPS n'est pas saturé.

    En insistant un peu en cliquant et recliquant le bouton enregistrer, ça finit par passer au bout de 3-4 essai.

    Pourriez-vous m'indiquer les pistes à suivre ?

    Version Prestashop : 1.7.6.5

  8. Bonjour,

    Je viens de prendre en main un Prestashop d'un client sur son VPS. Son MySQL sature souvent, et quand j'ai regardé, je vois qu'il n'y a pas de requêtes lentes sur le slow log, mais que les requêtes par secondes sont trop nombreuses : plus de 800 requêtes par secondes pour un seul site, alors que mon serveur MySQL mutualisé (une centaine de clients) n'accueille que 600-700 requêtes par seconde, tout site confondu.

    Je me dis alors qu'il y a un souci sur ce Prestashop, seulement, je ne vois pas où commencer l'investigation sur le site web. Y a-t-il des profileurs MySQL sur Prestashop 1.6.x ?

  9. 2 hours ago, hhennes said:

    Bonjour,

    Dans ce cas regarde plutôt mon projet : https://github.com/nenes25/prestashop_console
    Tu peux télécharger un phar directement à la racine de ton site prestashop et exécuter des commandes sans rien installer.
    La maintenance est géré via la commande https://github.com/nenes25/prestashop_console/blob/master/COMMANDS.md#preferencesmaintenance

     

    Intéressant. Est-ce compatible avec toutes les versions de Prestashop ?

  10. En activant le mode débogage, j'obtiens un ContextErrorException

    Notice: unserialize(): Error at offset 26 of 975 bytes

    Le truc à unserializer semble provenir de la base de données :

    a:17:{s:14:"/www/vendor";i:1580075433;s:37:"/www/modules/ps_contactinfo/vendor";i:1585298560;s:42:"/www/modules/ps_currencyselector/vendor";i:1582115180;s:43:"/www/modules/ps_emailsubscription/vendor";i:1581469263;s:34:"/www/modules/ps_linklist/vendor";i:1581469267;s:38:"/www/modules/ps_shoppingcart/vendor";i:1582115266;s:32:"/www/modules/statslive/vendor";i:1585298574;s:38:"/www/modules/psaddonsconnect/vendor";i:1580073274;s:39:"/www/modules/ps_buybuttonlite/vendor";i:1580073336;s:34:"/www/modules/ps_checkout/vendor";i:1585298546;s:39:"/www/modules/blockreassurance/vendor";i:1580292728;s:39:"/www/modules/ps_facetedsear'

    Ou est-ce que c'est un chargement de modules ?

  11. Bonjour,

    J'ai un "petit" souci avec le back-office du site de l'un de mes clients. En se connectant sur celui-ci, juste après avoir inséré le combiné identifiant/mot de passe, le site met un temps fou à se charger, et se finit par un timeout du service PHP-FPM (donc un erreur 503 du côté du navigateur).

    En vérifiant sur htop (étant donné que c'est un serveur VPS), j'ai trouvé qu'il y a pas mal de processus PHP-FPM qui surchargent le CPU.

    Après traçage avec un slow log PHP-FPM, j'obtiens l'événement qui semble être à l'origine du problème :

    [20-Apr-2020 08:00:00]  [pool www] pid 36413
    script_filename = /www/backoffice/index.php
    [0x00007f6e9c573bd0] getActionsByController() /www/src/PrestaShopBundle/Routing/Converter/LegacyUrlConverter.php:198
    [0x00007f6e9c573af0] getActionFromParameters() /www/src/PrestaShopBundle/Routing/Converter/LegacyUrlConverter.php:177
    [0x00007f6e9c573a40] findLegacyRouteNameByParameters() /www/src/PrestaShopBundle/Routing/Converter/LegacyUrlConverter.php:89
    [0x00007f6e9c5739a0] convertByParameters() /www/classes/Link.php:822
    [0x00007f6e9c573820] getAdminLink() /www/classes/controller/AdminController.php:2048
    [0x00007f6e9c5736e0] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6e9c573530] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6e9c573380] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6e9c5731d0] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6e9c573020] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252df0] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252c40] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252a90] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb62528e0] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252730] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252580] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb62523d0] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252220] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6252070] getTabs() /www/classes/controller/AdminController.php:2049
    [0x00007f6eb6251ec0] getTabs() /www/classes/controller/AdminController.php:2049

    Avez-vous une idée de ce que je pourrais corriger ?

    Type d’install : inconnu, probablement une MàJ, c'est un site que je viens de prendre en main
    Version de PS : 1.7.6.3
    Hébergement : VPS
    Version de PHP : 7.0.33 (Debian 9)
    Version de MySQL : MariaDB 10.1.44

    Merci d'avance.

  12. Bonjour,

    Je viens de rencontrer une chose assez bizarre sur un site Prestashop.

    Sa base de données est sur une ancienne version (PS_VERSION_DB = 1.6.x.x) alors qu'il utilise Prestashop 1.7. Du coup le schéma n'est pas très adapté, et ça bug un peu partout. Mais le plus important, c'est le serveur MySQL qui est totalement saturé à cause de ps_facetedsearch qui lance des requêtes avec des JOIN sans clés (rappelez-vous, le schéma de la base n'est pas à jour).

    J'espérais que remettre le dossier install sur le site et tenter un php install/upgrade/upgrade.php va mettre à jour la base de données, mais en fait celui-ci dit qu'on est déjà à la dernière version (erreur 28).

    Connaissez-vous un moyen de remettre à jour correctement la base de données ?

    PS : j'ai demandé au propriétaire du site, il n'a pas fait de sauvegarde.

  13. Bonjour,

    Je ne sais pas quel type de formule vous avez avec Infomaniak, mais étant moi-même consultant en support technique de plusieurs hébergeurs, je vous recommande, si vous y avez accès, d'activer le slow log de PHP-FPM : https://robertbasic.com/blog/php-fpm-slow-log/

    C'est ainsi que moi, je débogue des dizaines de sites lents par jour.

    Ceci affichera directement quelles fonctions PHP sont appelés par votre script et qui causent cette lenteur. Ainsi, on pourra distinguer facilement les parties du site, modules, ... concernés.

    De mon point de vue, s'il n'y a pas de surcharge sur le serveur de l'hébergeur, il n'y a généralement aucune raison que la lenteur provient de ce côté.

  14. Bonjour,

    J'apprécie vraiment l'utilisation de bin/console sur Prestashop pour vider le cache et pour activer/désactiver les modules. Celui-ci me permet de faire des scripts personnalisés en console SSH sans se connecter à l'interface Prestashop.

    Toutefois, j'aimerai savoir s'il est également possible d'activer et de désactiver le mode maintenance de Prestashop depuis le CLI et par quelle commande.

    Et dans un cadre plus global, existe-t-il une documentation, liste de commandes possibles, ... de bin/console pour Prestashop ?

    Merci d'avance pour vos aides.

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More