2011-05-24 68 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。

相關問題