Nginx從池中刪除上游服務器

我們的設置是標準的nginx（ver 0.7.59）+ Debian lenny上的精簡上游服務器。現在我們在網頁/應用程序和1分貝框的1牛腩框。最近我們開始注意到最終會開始「掛起」，即他們將不再接收來自nginx的請求。我們有15個運行，10-15分鐘後，第一個或第二個將被掛起。如果整天離開，那些相同的幾個加上幾個將繼續掛起。我們目前唯一的解決方法是重新啓動nginx。重新啓動後，掛起的薄片馬上會再次接收請求。正因爲如此，看起來這些稀有物可能已經被排除在上游泳池之外。Nginx從池中刪除上游服務器

如果我正確理解了文檔（http://wiki.nginx.org/NginxHttpUpstreamModule#server），並使用默認值（我們有），如果nginx在10秒內無法與後端服務器「通信」3次，則會將該上游服務器設置爲「無效「狀態。然後等待10秒鐘，然後再次嘗試該服務器。這是有道理的，但我們無限期地看到了瘦身吊掛。我試圖將max_fails設置爲0，但這並沒有幫助。我找不到會導致上游服務器永久「失效」的原因。

我們已經看到最近增長率的大幅增長，所以我們不確定它是否可以與此相關，或者由於更短時間內的更多流量而更加明顯。

在nginx中是否還有其他的東西（一個可改變的指令或其他條件）會導致它將服務器完全移出池？

來源

2009-08-31 Brian Ray

我們在nginx的反向代理支持方面遇到了很多問題，最終通過在Mongrel和nginx之間放置HAProxy實現了更好的體系結構。因此，我們的架構是：

網=> nginx的=> HAProxy的=>的Mongrels

我們前面所看到的（前HAProxy的）是nginx的可能淹沒的Mongrels太多的請求和雜種的請求隊列不可靠，而且很快就會遇到太多排隊的請求。 HAProxys隊列更加穩定，它比nginx更好地平衡了後端之間的所有請求。當真正像最少連接這樣的算法更好時，nginx只提供循環平衡。我不知道Thin是否與Mongrel有同樣的問題。

在我們的新設置中，nginx只是代理一個haproxy實例，而haproxy已經配置了所有已註冊的Mongrels。 HAProxy更好地支持上游的ok/fail檢測，並且還可以將每個應用服務器限制爲1個連接（maxconn指令），這對於Mongrel來說很關鍵，對Thin不是很確定。

maxconn指令非常關鍵，EngineYard爲nginx提供了一個補丁，它使它成爲nginx的本地補丁，所以您不需要部署HAProxy來利用它。

參見：nginx-ey-balancer

來源

2009-08-31 16:28:03

是的，我們會看到，之前，我忘了提，我們使用的公平代理平衡器插件（http://brainspl.at/articles/2007/11/09/a-fair- proxy-balancer-for-nginx-and-mongrel; http://wiki.nginx.org/NginxHttpUpstreamFairModule），它使用最不忙的算法而不是循環法。它運作良好，＃request/thin甚至可以隨時間變得非常接近。我希望不必引入像HAProxy這樣的其他圖層，只要我們能夠找出導致圖層不再接收來自nginx的請求的原因。那麼nginx-ey-balancer基本上模仿了HAProxy的w/max H算法需要HAProxy？ – 2009-08-31 16:45:54

是的，nginx-ey-balancer模仿HAProxy需要HAProxy的maxconn算法。這幾乎是我們轉向haproxy開始的全部原因，現在它只是我們架構的一部分。 – 2009-08-31 16:50:18

非常感謝您的幫助。想想我會嘗試nginx-ey-balancer。雖然它只有nginx v 0.6.34/35和0.8.0的補丁。我會看看哪一個更接近0.7.59，並希望最好..或等到0.8.x穩定。 – 2009-08-31 17:00:07

Nginx從池中刪除上游服務器

回答

相關問題