Re, et merci pour la réponse.
Le lundi 01 décembre 2014 à 21:20 +0100, FoxMaSk a écrit : > Hello, > j'aurai bien fait une vanne sur "mais quelle hérésie une biere au pays > du rouge" mais bof ouais, je suis pas sectaire sur la boisson ;-) > Par contre que disent les logs du SGBDR ? Quelle est-elle ? Oracle ? > Postgresql ? PostgreSQL 9.3 sur http://1flow.io/ et ma machine de dév, et 9.1 sur d'autres instances. Le problème est commun aux deux versions, et se produit avec DEBUG=True et DEBUG=False. > Là, genre, paradoxalement, j'aurai plutôt conservé des connexions > persistantes (si elle ne le sont pas) et je me demande s'il n'y a > justement pas assez de cursors ouverts pour traiter toutes les demandes, > ce qui du coup, lorsqu'arrive le moment d'en traiter une, > qui n'a plus "sa place" ; lâche. Les logs de PG n'indiquent rien de particulier au moment des problème, ce qui est plutôt rassurant (ou pas) : lorsque les crash se produisent avec transaction.atomic(), en fait il n'y a aucun problème particulier ; j'en veux pour preuve que si je l'enlève, tout va bien (sauf un cas d'erreur légitime sur X milliers de requêtes). Les logs de PG ne sont pas vides, loin s'en faut, mais ils ne contiennent que des : 2014-11-30 17:20:23 UTC ERROR: duplicate key value violates unique constraint "core_article_url_key" 2014-11-30 17:20:23 UTC DETAIL: Key (url)=(http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_le_monde_metal/) already exists. 2014-11-30 17:20:23 UTC STATEMENT: INSERT INTO "core_article" ("baseitem_ptr_id", "url", "comments_feed_url", "url_absolute", "url_error", "is_orphaned", "ima ge_url", "excerpt", "content", "content_type", "content_error", "word_count") VALUES (16918397, 'http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_ le_monde_metal/', NULL, false, NULL, false, NULL, NULL, NULL, NULL, NULL, NULL) Qui sont les erreurs « normales » qui se produisent lors des get_or_create() ou des update_or_create() (ah non mince lui c'est que dans Django 1.7 ; en 1.6 je ne l'ai pas. Bien dommage d'ailleurs. Bref.) > Mais avant de partir trop loin en conjecture, les logs seraient pratique. Ben voilà. Je peux te mettre un log en accès FTP qq part, mais à première vue c'est peine perdue. Sans compter qu'une journée de log, c'est 200Mo minimum, à tendance 1.5Go… Si vraiment vous êtes demandeurs, je ferai un extrait avant / après activation d'atomic(). Je viens de lire la doc des connexions persistantes, ça a l'air alléchant. Pour l'instant, je n'ai rien changé (j'essaierai plutôt demain, après une nuit de sommeil…). J'avais monté le nombre de connexions parallèles à 256 dans postgresql.conf pensant que ça pouvait éventuellement être lié (sans grande motiv' parce que je vois pas pourquoi, en fait), mais ça n'a rien changé. Faut dire qu'avec la configuration par défaut (100 connexions je crois), ça passait très bien, et avec le bug que je rencontre sur atomic(), quelle que soit la valeur, ça pète. a+ et merci aux courageux qui lisent mes mails jusqu'au bout. Bonne nuit, -- Olivier http://oliviercortes.com/ http://1flow.io/ _______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
