2011-05-24 78 views
2

在工作中,我们在rails中运行一些高流量站点。我们经常会得到一个问题,在Nginx的错误日志中的垃圾资讯:Nginx + unicorn(rails)在nginx错误日志中经常给出“连接被拒绝”

2011/05/24 11:20:08 [error] 90248#0: *468577825 connect() to unix:/app_path/production/shared/system/unicorn.sock failed (61: Connection refused) while connecting to upstream 

我们的设置是前端服务器(负载平衡),以及麒麟我们4台应用服务器上nginx的。每个独角兽都有8名工人。该设置与GitHub使用的设置非常相似。

我们大部分的内容都被缓存了,当请求到达nginx时,它会在memcached中查找页面,并在找到该页面时提供该页面 - 否则请求会转到rails。

我可以解决上面的问题 - 通过做后跟一个服务器上的麒麟过程的pkill的 - 有时:

cap production unicorn:check (removing all the pid's) 
cap production unicorn:start 

你们是否有任何线索,我该怎么调试这个问题?当这些问题发生时,我们在数据库服务器上没有任何明显的高负载..

回答

0

某个东西在您的某个服务器上死掉了您的独角兽进程,或者它超时了。或者,您的上游应用服务器{}块中有一个旧应用服务器不再有效。 Nginx会不时重试它。默认情况下,如果出现连接错误,则重新尝试其他上游,因此希望您的客户没有注意到任何事情。

+0

今天发生在我身上的事情,在使用unix套接字连上3天gunicorn(v18.2)上行之后,我得到了拒绝上行的连接。袜子文件仍然存在,当我检查ps -aux时,gunicorn仍在运行。我正在使用eventlet,最新版本0.14。如果这个问题依然存在,我将切换到uWSGI/gevent – radtek 2014-01-20 03:44:22

+0

如何在本地测试一个unix套接字?当我使用TCP套接字时,我可以通过使用lynx连接到localhost:8000来轻松地进行测试。 – radtek 2014-01-20 03:56:08

0

我不认为这对我来说是一个nginx问题,重新启动nginx并没有帮助。它似乎是一炮而红......避免这种情况的一种快速和肮脏的方法是在系统未被使用时回收这些炮弹,例如,如果这是一个可接受的维护时间,例如上午1点。我跑gunicorn作为一个服务,它会回来了,如果杀了这么一个pkill的脚本采用循环/重生的护理:

start on runlevel [2345] 
stop on runlevel [06] 
respawn 
respawn limit 10 5 
exec /var/web/proj/server.sh 

我开始怀疑,如果这是在所有涉及到内存分配。我有MongoDB在同一个系统上运行,它为自己保留所有的内存,但如果其他应用程序需要更多的内存,它应该会产生。

其他值得一试的事情是在运行gunicorn时摆脱eventlet或其他依赖模块。 uWSGI也可以用来替代gunicorn。

相关问题