GIGABIT 網路效能,請教各位網友.



贊助商連結


頁 : [1] 2

天堂之路
2009-11-29, 10:32 AM
先說明目前的使用環境,

多媒體影音伺服器一台(10/100網路卡,2T硬碟陣列),10/100 SWITCH數台,
XP使用者50台左右(10/100卡,硬碟120G),
檔案為MPEG2或是MEPEG4大小約在30-200MB左右,檔案數量在2萬個左右,
使用者在搜尋檔案時會先搜尋本地端的硬碟是否有檔案,
沒有的話會搜尋同一群組(8-16台電腦),看是否有檔案可以下載,
如果沒有,即連線到伺服器下載.

目前的情況是當全部的使用者(超過30個)在使用時,常會發生網路斷線,
或是連不上伺服器的情形.
設備廠商建議升級先升級GIGABIT SWITCH,
只是不知道效能是否可以達到預期.

小弟是想說,如果將伺服器網路卡升級為2-4埠的1G網路卡,
然後SWITCH的部分使用TRUNK的方式結合頻寬,
不過廠商卻建議伺服器不如換一部新的,
然後使用者的網路卡或是電腦也都要換新.
不過這樣子起來整體的預算超過太多:mad:

不知道是否有其他的組合或是建議,可以達到比較高的經濟效能能.

或是分期建設,先升級哪些設備,等到一段時間之後再升級主要設備,
可以建議一下優先的升級順序嗎,謝謝各位.

贊助商連結


mis339
2009-11-29, 11:41 AM
先試著找出頻頸是在網路流量還是伺服器還是交換機?
再更換或升級相關的設備。

如果是我,我可能會試著先買一台5或8 Port的Giga Switch加一張Giga的網卡接在伺服器上來測,看看是否有所改善。這樣的成本很低,但很快能抓出原因。

站在設備廠商的立場,當然是你都換最新、最快、最貴的設備最好!呵~

FYI
2009-11-29, 12:42 PM
目前的情況是當全部的使用者(超過30個)在使用時,常會發生網路斷線,
或是連不上伺服器的情形.
不懂....

哪個品牌的 "串流影音伺服器" 或者只是DIY 的 "檔案伺服器"?

天堂之路
2009-11-29, 03:22 PM
不懂....

哪個品牌的 "串流影音伺服器" 或者只是DIY 的 "檔案伺服器"?

某個市面上某大KTV的影音伺服器,這一類的公司,檔案伺服器都是DIY的,
並非品牌的檔案伺服器,通常都是LINUX的系統,
不過,這些公司的重點都是在使用者端(點歌軟體,會計系統),
至於整個網路的效能,每次有問題就是要求升級硬體.

我是有要求在伺服器出來後裝一台 1G 5埠的SWITCH,
再加台電腦監看網路流量,不過,現場不配合,
現場的店長怕有問題會影響生意,現場是24小時營業的.

老闆的意思是要求評估廠商的建議,並沒有要求我去處理,
因為,廠商如果處理之後有問題,可以要求賠償或是折抵貨款,
如果是我處理有問題,老闆又不能扣我薪水,
所以我只能被動的依照現場狀況尋找比較好的解決方式.

補充一下,廠商並沒有提供系統操作者的權限,所以,我也無法自行加裝或是變更伺服器硬體.

FYI
2009-11-29, 04:28 PM
你還是沒有詳述網路斷線情形, 以及發生問題時如何排除?

目前所使用的交換器是全新的嗎? 多少埠? 廠牌型號? 建議先加強散熱, 交換器熱當機率頗高

工作站若為XP Pro + 點歌系統, 則群組內的搜尋原則為何? 如何設定?

如果視訊規格是DVD-Video 的話, Raw bitrate 11.08 Mbit/s, 50 個包廂則需要550 Mbit/s, 那麼伺服器的100Mbps 網卡應該早就不夠用才對, 建議先詢問廠商當初是如何規劃的, 否則只升級交換器, 卻不升級伺服器網卡, 那也是白費功夫, 至於工作站網卡是否需要升級, 則必須通盤考慮瓶頸為何, 群組大小和硬碟的持續傳輸效率息息相關, 只升級網卡和交換器不見得有效

如果以100Mbps 網卡為基礎, 實際效能約75Mbps (Intel 8255x) 來看, 則在最糟糕的情形下, 一個群組以7~8 個工作站為宜, 瓶頸在於網路, 不在於硬碟, 但螃蟹卡效能較差, 所以必須全盤考慮

天堂之路
2009-11-29, 06:07 PM
包廂使用者的設定是100G的儲存空間,這個空間內放到放不下後,依照使用次數將使用次數最少的檔案刪除,再看看空間是否足足夠,不足再刪除其他檔案,當點播歌曲的時候,先尋找硬碟,然後看同一個群組的硬碟空間是否有這個檔案,有的話下載到本地端的硬碟儲存後播放,如果群組沒有就向伺服器抓取檔案儲存後播放.

理論上來說,常被點播歌曲約在1500首上下,扣常本地端的存放歌曲後,約有六分之一的機會需要跟伺服器抓取檔案,也就是說同時間應該不會超過10個使用者以上與伺服器連線,每首歌曲 bitrate 最大不會超過 8Mbit/s,一首歌曲預估下載時間在40秒上下,萬一超過90秒下載時間即會更換下一首歌.

通常即使在滿載的情況下,點播排行前1500首通常會在群組內找的到,問題是只要點到這個範圍之外,就常會發生下載超時的情形,包廂內一直不會播歌,因為每一首歌的下載都是超過90秒無法完成.

目前的猜測是伺服器與主幹線無法供應下載所需頻寬.

FYI
2009-11-30, 12:03 AM
小弟自己想岔了, 由於不是串流, 所以和bitrate 無關, 純粹只是檔案伺服器, 所以和硬碟傳輸率以及網路傳輸率有關, 按照你的說明, 不像是網路斷線, 而是效能不足以在90 秒內將檔案下載完畢, 瓶頸很可能是卡在伺服器的100Mbps 網卡, 若暫且不計overhead, 則

75Mbps x 90s / 8 = 843.75MB
也就是100Mbps 網卡於90 秒內只能傳送843.75MB, 如果不巧一個檔案就200MB, 那麼只要同時有五台工作站要檔案, 那就會出問題, 同樣情況也可能發生在群組內相互要檔案, 所以小弟才會建議群組不要大, 否則只好全面換成GbE 網卡和交換器, 可見事先規劃很重要, 考慮不周詳, 自然容易遇上問題

然而你還是沒解釋群組內如何搜尋, 建議你還是直接詢問廠商, 先把架構和規劃原理弄清楚

wangcm
2009-11-30, 03:06 PM
這看來很像是file server和squid這類hierarchy cache的綜合體,的確會遇到FYI兄提到的狀況,換GbE是比較直覺的方式,可是還是改成streaming方式才算治本(降低server/backbone的loading,畢竟這類AP不須要急於榨乾server/backbone的performance,只要表現正常即可:p),不過要動到client就茲事體大了:sleep::sleep:....

天堂之路
2009-11-30, 06:27 PM
群組內的蒐尋,廠商是說使用廣播UDP的方式,然後以最快回應的做為優先,當這台電腦超過5個連線,對於廣播不會回應.

舉例來說,A電腦需要A1.mpg這個檔案,程式如果在本地端的硬碟找不到即會發出廣播(UDP封包),其他台電腦如果本地端的硬碟有這個檔案且連線數未超過5個話就傳出回應,收到回應後.A電腦會FTP到那台電腦下載後再播放,如果再5秒沒有電腦回應,就會直接FTP到主伺服器下載.

最早的系統(10年前)是預先下載10秒後就開始播放,不過,滿載常發生會播放時停頓的現象,所以後來改成下載完才播放,以前檔案數量沒那麼多以及大小也沒有那麼大,檔案大小超過100M的很少通常50M左右,總數量也都維持不超過1.2萬,這一兩年的檔案每一個都是超過100M,總數量目前已超過兩萬,所以系統越來越不敷使用.

FYI
2009-11-30, 09:23 PM
建議找一台電腦安裝監控程式, 或者借一台有網管功能的交換器, 實際觀察問題出於群組內搜尋, 亦或向伺服器要檔案

此外, 就算能在90 秒內下載完畢, 還是會有空等的感覺, 既然程式已經有分散式的邏輯, 為何不能一邊快取一邊播放?

#1 提到群組為8~16 台電腦, 請問是以交換器的埠數區隔嗎? 那麼應該是7 或15 吧? 既然是100M 交換器, 別忘了串接也會受限於100M, 也就是一個群組如果同時有5 台工作站向伺服器要檔案, 這也可能會產生問題