2015-03-31 76 views
3

我們在c4.8xlarge類型的AWS EC2中託管了一個站點。這是一個相當大的系統,擁有大量的內存和計算資源。成千上萬的用戶在本週末的2小時內嘗試訪問系統。雖然它沒有崩潰,但它有所減緩並且未能達到預期水平。分析統計數據顯示,有限的網絡帶寬是造成經濟放緩的主要原因。 CPU使用率保持在6%以下,但NetworkIn和NetworkOut在該時間段內似乎分別達到了60MB和200MB的峯值。雖然我不是網絡預期,但在線閱讀似乎表明所有通過一個網卡的流量都可能是網絡帶寬有限的主要原因。這是真的?將該網站託管在不同類型的EC2實例上有助於增加網絡帶寬?以下是networkIn和networkOut指標在重負載下的樣子。如何增加AWS EC2實例的網絡帶寬?

networkIn and networkOut metrics chart

+3

爲什麼只有一個實例?你可以水平放大嗎? – 2015-03-31 14:39:50

+0

我可以,也許我應該。我瞭解與單一實例相關的風險,但該應用程序幾乎沒有商業價值,而且這些風險都是可以接受的。這是一年一次的事情。水平伸縮以滿足CPU或內存或存儲器的限制是可以理解的,但僅僅爲了獲得更高的帶寬而這樣做似乎是一件令人失望的事情。儘管200MB NetworkIn和60MB NetworkOut似乎太低,但可能是我錯了。我甚至不確定它是否每秒。 AWS CloudWatch沒有明確說明。 – 2015-03-31 17:16:41

+0

雖然您的實例有10 Gbit網絡接口,但它不清楚它應該能夠實現從ec2到互聯網的性能,或者性能是否限於實例間通信。整個你得到的是1.8 Gbps左右的開銷。你有沒有啓用增強的網絡? http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html – datasage 2015-03-31 23:11:44

回答

-1

是亞馬遜ENI的概念 - 彈性網絡接口。雖然您可以爲實例添加額外的NIC;它仍然是一個邏輯接口。網絡管道的供應和可用性高度依賴於(完全取決於)您選擇的類型實例。 Amazon在內存,IO,計算,密集存儲,GPU上分別具有R,I,C,D,G等幾種類型/實例。你可以看看你是否可以擠壓最大。在他們之外。

無論你選擇什麼樣的實例類型,你基本上都會達到一個門檻,並且無法在某個點之外進行縮放。可伸縮性對內存/ CPU等其他可伸縮性因素尤其獨特。

修改您的架構,而不是讓大型/大型實例擁有幾個大型或中型實例和ELB。

+0

謝謝。基於我上面的評論的任何其他想法? – 2015-03-31 18:14:18

+0

如果您仍然需要通過具有類似甚至更低帶寬限制的負載均衡器,那麼如何讓多個實例有所幫助? (假設你仍然使用一個ec2實例作爲你的負載均衡器,安裝了類似haproxy的東西)。 – stepanian 2015-12-20 10:41:38

+0

儘管不是臀部,但放大是一個可行的解決方案。 **整個站點和所有Stack Exchange **僅在[25臺服務器]上運行(http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-服務器和-i.html)。他們表示,他們實際上可以只使用一臺Web服務器運行,其服務器的規格與c4.8xlarge非常相似(但具有更好的存儲空間)。我嚴重懷疑它們在這裏達到了垂直縮放限制,這可能是配置或代碼問題,而不是硬件限制。 – BobMcGee 2016-04-01 23:22:36

5

如果您受限於帶寬,那麼當您達到限制時,該圖將變得平坦。此外,正如其他人指出的那樣,每秒只有1MB/s和3MB/s,而我可以在外部互聯網上做的比t2.micro多。

系統對每個請求執行什麼操作?這裏列出一些我將要看到的東西,按順序排列:

  • 線程:應用程序中是否存在瓶頸,只有一個線程可以訪問資源?這將保持CPU使用率低,但造成你看到的模式。
  • 您的應用程序或服務器中的併發性不良模式。加載測試並查看它隨着連接的增加而變得越來越慢,而無所事事。
  • 獨立CPU:一個CPU加載到100%而其他CPU空閒? (有30多個內核,飽和的CPU只會讓你使用3%的CPU)。一個飽和的CPU +其他空閒通常意味着一個併發問題,可能在連接處理中。
  • 什麼是內存使用像?你是否在使用交換? (如果是這樣,這是一個非常糟糕的跡象,並會導致問題)。如果內存使用過度,內存中的會話存儲或過大的處理程序線程池都會出錯。
  • 磁盤I/O或外部網絡請求:您是否在讀取或寫入每個請求? vmstat會告訴你是否花了很長時間等待I/O服務。如果是這樣的話,我會在任何事情之前查看日誌。
    • c4.8xlarge實例只使用EBS,如果存儲是磁性的,並且您要寫入訪問日誌,則每秒會寫入幾百次寫入。通用固態硬盤爲您提供每GB 3個IO/s的基礎,但可以突破3000,直到用完IO積分。
    • 操作系統將嘗試結合寫,但成千上萬的併發

這不是不可能,但可能性非常小,你可能會在與創建連接或數據包每秒的網絡層瓶頸, 如果您的請求非常小。

0

您的NetworkIn和Out實際上是> 50mb/s。如果你的CPU和內存保持在合理的範圍內,那麼你的實例很好。您還應該檢查數據庫上的連接日誌(假設您在系統中運行RDB),實際上可能是由於數據庫響應緩慢導致Web服務器響應速度變慢。

另外,您應該使用AWS負載均衡器以及帶有網絡輸入/輸出觸發器的setup和autoscaler運行系統。通過這種方式啓動輔助實例來協助臨時增加網絡負載。如果根本原因確實是數據庫連接的增加,那麼負載平衡器將無助於解決問題。相反,您希望改進緩存設置,以便減少每個用戶/連接到您網站的數據庫負擔。