2011-12-02 3 views
0

J'ai installé le nouveau magasin Satchmo sur Linux Debian 6 distributive. Le serveur de développement standard de Django fonctionne parfaitement, mais en mode de production avec nginx + FastCGI après un certain temps (ou il semblerait qu'après que certaines limites de mémoire soient dépassées) Erreur de sortie nginx "502 Mauvaise passerelle".Django + Satchmo en utilisant nginx + FastCGI après un certain temps donne HTTP Erreur 502 Bad passerelle

dans les fichiers journaux que je trouve ces lignes:

2011/12/02 02:38:57 [error] 29894 # 0: * 91439 recv() a échoué (104: Connexion réinitialisée par les pairs) en lisant l'en-tête de réponse en amont, client: 2.95.158.164, serveur: my-secret-host.com, demande: "GET/ HTTP/1.1", en amont: "fastcgi: // unix:/var/run/www /file.sock: », hôte: "my-secret-host.com"

Je cherchais sur internet beaucoup et trouvé nginx ne peut pas obtenir ri réponse ght de mon serveur django fastcgi. J'ai essayé différents paramètres de serveur django (maxchildren, maxrequests), mais l'erreur est toujours là (conclusion est des valeurs plus élevées - durée de vie plus longue sans erreur). Avec les paramètres maxchildren = 3 maxrequests = 10 erreur apparaît aléatoirement après 5-10 actualisations de page et après 15 actualisations il apparaît toujours.

J'ai également trouvé quand je commente que certaines lignes d'erreur de code source satchmo ont disparu. C'est très étrange, car ce sont des lignes très importantes pour le bon magasin de travail. Je pense que cela peut être un indice de la raison du problème. Diff est ici: http://dpaste.com/hold/664978/

problème disparaît si je voulais:

  • commentaire sur la ligne PAYMENT_PROCESSOR=True dans mon seul module de paiement.
  • commentaire sur config_register(MultipleStringValue(SHIPPING_GROUP, ...) dans shipping/config.py

Je pense que ces lignes conduisent à des raisons réelles de s'écraser mon serveur de production. Comment je peux résoudre ce problème complètement? Des suggestions à mon enquête?

MISE À JOUR:

Après avoir activé l'enregistrement de Satchmo je trouve ce message:

Lun 5 décembre 2011 13:26:37 configuration erreur Problème pour trouver paramètres SHOP.SHOW_SITE, serveur fermé la connexion inattendue Cela signifie probablement que le serveur s'est terminé anormalement avant ou pendant le traitement de la demande.

Il est probablement possible de résoudre ceci en utilisant la recette d'ici https://groups.google.com/group/satchmo-users/browse_thread/thread/506b3ad77e7a766e?hl=es&pli=1. Je vais essayer ça un peu plus tard.

Répondre

0

Vous devriez jeter un oeil à vos fichiers journaux Satchmo et voir s'il y a plus de détails sur la raison de ce plantage. Les éléments que vous avez commentés ne devraient pas empêcher un crash, donc je suppose qu'il se passe quelque chose d'autre avec votre configuration de déploiement.

Un autre élément à considérer, utilisez-vous un Fast-CGI fileté vs non-threaded?

+0

mis à jour avec un message de Satchmo log – ramusus

+0

Django est en cours d'exécution avec la commande 'Méthode runfcgi = prefork'. Quelle différence pour satchmo? – ramusus

0

Ceci est dû à un problème avec la connexion de base de données.

Raison: La première partie du message d'erreur "ERROR de configuration Problème de recherche de paramètres SHOP.SHOW_SITE" provient de paramètres de vie. C'est généralement le premier module qui utilise la base de données. La deuxième partie après la virgule "serveur a fermé la connexion de façon inattendue ..." est un message du client de base de données Postgres sur la connexion au serveur DB.

connexion de base de données, le nombre de connexions actives et paramètres db peut être testé par les commandes suivantes:

$ python manage.py dbshell 

postgres=> select * from product_product; -- something typical 
postgres=> select * from pg_stat_activity; -- active connections 
postgres=> show all;      -- show current db server settings 
Questions connexes