【问题标题】:A curious case of nginx uswgi python一个奇怪的nginx uwsgi python案例
【发布时间】:2015-01-18 04:40:40
【问题描述】:

我们有一个使用(werkzeug、jinja2 和 MongoEngine)构建的 python MVC Web 应用程序。

在生产中,我们在 nginx 负载均衡器后面设置了 4 个 nginx 服务器。所有 4 个服务器共享一个公共的 Mongo 服务器、一个 Redis 服务器和一个 Sphinx 服务器。我们在 nginx 和应用程序之间使用 uwsgi。

现在来看看奇怪的案例。

一旦我们部署了一个新代码,我们就会做一个 touch xyz.wsgi。几个小时后,一切看起来都很好。 但在那之后我们随机得到错误。

 'module' object is not callable

我之前在其他python开发场景中看到过这个错误。但这次让我感到困惑的是完全随机的行为。

例如example.com/multimedia?keywords=sdf&s=title&c=21830

如果我们刷新错误就消失了。为任何参数尝试另一个值,如“keywords=xzy”,它又出现了。刷新它消失了。

那个“多媒体”模块是我们最近才做的。所以我们可以假设它的根本原因。但是为什么会随机出现错误呢?

我的假设是,它可能与 nginx 缓存或 pyc/pyo 的存在有关?一个非法的全局变量可能是原因吗?

请各位高手帮帮我。

【问题讨论】:

  • 堆栈跟踪?还要别的吗?问题是否总是在相同的请求(相同的 URL 和 GET/POST 参数)之后出现?
  • 例如。 'example.com/multimedia?keywords=sdf&s=title&c=21830'。如果我们刷新 URL,错误就消失了。为参数“关键字”尝试另一个值,它又出现了。刷新它已经消失了
  • 是否有指向错误所在位置的堆栈跟踪?

标签: python caching nginx uwsgi pyc


【解决方案1】:

该错误可能是随机发生的,因为它是您代码中的运行时错误。也就是说,在用户以正确的条件访问您的网站并遵循导致此错误的代码路径之前,它不会被触发。

这不太可能是 nginx 缓存问题。如果它正在缓存它,那么它可能会一遍又一遍地返回相同的结果,而不是在重新加载时改变。

但是,您可以通过删除 nginx 并直接针对 werkzeug 进行测试来进行测试。针对它运行请求,看看您是否看到相同的行为。除非你能证明底层系统按你期望的方式工作,否则调试 Nginx 是没有用的。

在您的代码中搜索 module() 可能也值得花 30 秒时间,因为这是对该错误消息的最直接解释。

【讨论】:

  • 如果我们重新启动 nginx,它会消失几个小时。它也没有出现在开发环境中(它使用像django这样的开发服务器而不是nginx)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-17
  • 2011-11-26
  • 2012-07-02
  • 1970-01-01
  • 2013-06-01
  • 1970-01-01
相关资源
最近更新 更多