請教20萬到30萬的預算做計算服務器是用機群好還是買一臺4or8cpu的服務器好？

nntp

原帖由 soway 于 2006-2-23 08:44 發(fā)表


linux里邊有一個重要的經(jīng)驗:一個cpu核(這里也可以是intel的超線程,比如一個intel dualcore的cpu,相當于有4個)只能跑一個進程.
如果多了,你的性能會有很大影響,usr占用時間減少,sys占用cpu時間增加.

這點在 ...

soway,你說的情況在Intel 平臺上的確如此的，所以我們高性能科學計算的項目，很多用戶都選擇了AMD64.

希望關(guān)注計算的朋友關(guān)注AMD64.  從AMD64開始，AMD和Intel的x86平臺開始分道揚鑣.  AMD公司得到了dec 的技術(shù).

nntp

原帖由 yangpeip 于 2006-2-22 23:15 發(fā)表
非常感謝soway和版大的建議

我們的license是學校統(tǒng)一購買的，倒是足夠用
soway剛才說的經(jīng)驗我在實際應用中都有深刻體會hehe

不過感覺linux的調(diào)度確實不太好，人多的時候有的時候像死機一樣
不知道這是操作 ...

linux 的調(diào)度，還是linux上的作業(yè)調(diào)度器?

我有一個項目，需要實時從國家骨干網(wǎng)的對外接口采集數(shù)據(jù)，網(wǎng)卡程序是特殊的,用戶研發(fā)部重新編寫的. 平臺是AMD64 dual core 4way服務器，用的是SLES9 AMD64版本.

常規(guī)文件系統(tǒng)已經(jīng)無法支持吞吐要求，我們每個這樣的設(shè)備用了32GB內(nèi)存，內(nèi)存中開出2個8GB 空間mount 到VFS上給應用作存儲. 15分鐘后，2個8GB mounted fs全滿.然后refresh到一個后臺去，重新開始采集. 這個吞吐量大了吧?  我配合客戶幾乎選擇了能夠選擇所有l(wèi)inux和幾個主要的服務器硬件架構(gòu)，最后選擇了上面的那種配置.
CPU在處理過程中一直維持在80%一上的高負荷. 由于采集的數(shù)據(jù)都是小于30k的極小文件，沒有一個fs符合要求，包括我們測試的lustre.常規(guī)的就更加不說了.
程序是java+C寫的，C部分我們用pathscale 優(yōu)化編譯過.

僅供參考.

還有， 感覺到linux 系統(tǒng) frozen 這個現(xiàn)象，不能直接推導出linux的調(diào)度有問題， 我給客戶作 Rsoft Fullwave 科學計算集群的時候，fullwave 的運算設(shè)計有一些很特殊的地方，如果計算的空間設(shè)置不當?shù)脑挘�也會導致linux compute node死鎖.  難道這就可以說linux 調(diào)度有問題? 說這個問題，還是要嚴謹點的，不可以太過于武斷.

客觀的來說,  2.4的時代，和sun solaris比，的確不能比，但是 2.6以及計算平臺向AMD64/EM64T 過渡，現(xiàn)狀就不是這樣了.

我們還是往前看吧.

yangpeip

原帖由 soway 于 2006-2-23 16:41 發(fā)表


說實在話,我挺喜歡LSF的,這個東西做的比較積極.唯一缺點就是價格貴.
所以,我后來沒太多機會接觸.
他們做的系統(tǒng),配置感覺非常方便,文檔寫的也不錯.

以后好好研究一下SGE

AMD opteron的機器,最近用了兩 ...

AMD和intel的對比我做過一些
跑hspice, 2threads, opteron 246*2比xeon 2.8G*2快了將近1/3
另外一個雙核的AMD64 X2 3800+跑同樣的，opteron 246*2仍然比之快了1/4
但是用spectre，X2 3800+就和opteron 246*2差不多了

我想可能是hspice內(nèi)存比較省，opteron的cache比3800+多一倍的優(yōu)勢體現(xiàn)出來了
而spectre占用內(nèi)存比較，需要頻繁和內(nèi)存交換，瓶頸就在內(nèi)存上了

yangpeip

原帖由 nntp 于 2006-2-23 11:47 發(fā)表



linux 的調(diào)度，還是linux上的作業(yè)調(diào)度器?

我有一個項目，需要實時從國家骨干網(wǎng)的對外接口采集數(shù)據(jù)，網(wǎng)卡程序是特殊的,用戶研發(fā)部重新編寫的. 平臺是AMD64 dual core 4way服務器，用的是SLES9 AMD64版本. ...

hehe，這個只是我們的一個感覺而已，當然不能全盤否定linux
您說的例子，cpu load在80%左右，我們的情況不太一樣，
如果是一個雙cpu的node，扔一個仿真進程，load就是50%，兩個就是100%
這個時候再登陸干別的，感覺就非常卡

而sun在這種情況下雖然慢，但是感覺還是在慢慢的動，linux感覺是等半天不動，然后突然動了一下，然后接著死。。。給人的感覺不是很爽的樣子hehe

ljhb

原帖由 soway 于 2006-2-23 08:44 發(fā)表


linux里邊有一個重要的經(jīng)驗:一個cpu核(這里也可以是intel的超線程,比如一個intel dualcore的cpu,相當于有4個)只能跑一個進程.
如果多了,你的性能會有很大影響,usr占用時間減少,sys占用cpu時間增加.

這點在 ...

lz說的是以前吧，建議你看看O(1)調(diào)度再說

ljhb

原帖由 soway 于 2006-2-23 19:32 發(fā)表


我跑的是vcs的simv,結(jié)論是246比XEON 2.8G慢5%,而DC快30%

intel amd在科學運算上各有長處，有些科學運算軟件針對sse3作了優(yōu)化

yalung

終于看完了討論，呵呵，，nntp兄，想向你咨詢一件事，希望聽聽你對X-Cat做HPC的看法，請多多賜教，也可以隨時加我MSN： wake_young@hotmail.com

nntp

原帖由 yalung 于 2006-3-1 08:19 發(fā)表
終于看完了討論，呵呵，，nntp兄，想向你咨詢一件事，希望聽聽你對X-Cat做HPC的看法，請多多賜教，也可以隨時加我MSN： wake_young@hotmail.com

Hello X-cat我不是很熟悉,略有耳聞. 因為我做的項目的限制，目前我做的hpc項目有2類，一類是采用商業(yè)的方案，一類是采用opensource的方案，32節(jié)點以下的小項目大多采用的是opensource的方案。采用opensource的方案又有2種，一種是用戶的應用是homegrown的，所以沒有辦法用現(xiàn)成的系統(tǒng)，所有的架構(gòu)都是自己搭的。如果用戶跑的是比較標準的科學計算應用，一般我就用ROCKS了.

之前這里有一個朋友談了點關(guān)于對Rocks的看法，我個人的看法是，有時候作技術(shù)而不是做項目的人往往容易絕對化一個事情，在我看來，技術(shù)沒有絕對的好壞之分，去苦苦比較尋找一個\"好的\"技術(shù)和系統(tǒng)，比把正確的技術(shù)方案用在正確的項目中，要容易得多。而后者往往是決定了用戶的最終使用的感覺體驗.

hpc的項目做得不算少了，依照我的經(jīng)驗，32節(jié)點的常規(guī)應用hpc集群，用ROCKS是最佳選擇。因為現(xiàn)在hpc 集群擴充的時候，我們有了第二個選擇，就是升級計算網(wǎng)，這個是一個國內(nèi)用戶可以考慮的新思路，以往規(guī)劃的時候，都是考慮以后是否可以擴充節(jié)點，但是我認為因地制宜的升級計算網(wǎng)，在現(xiàn)在來看，已經(jīng)是性價比非常好的選擇了. 比如從32node GbE到32node Infiniband(copper)，采用1:4的 block 阻塞，成本非常低廉，但是性能提升特別明顯，最關(guān)鍵的是MPI延遲將會從ms級降低到us 級別. 對于一些分布依賴性比較強的應用，比如中尺度天氣預報用的MM5，F(xiàn)luent之類的都有很強的提升作用. 特別是有些研究機構(gòu)和學校的材料和熱分子動力專業(yè)，他們的計算不像MM5那樣，需要越多結(jié)點越快地交換，像Material Studio這種系統(tǒng)，如果你用SGI 的IA64 設(shè)備，大概到4節(jié)點8cpu的時候，性能曲線就開始平緩下來了，過多的節(jié)點擴展根本不會給性能提升帶來太多的好處.

說了這么多擴展的問題是，我個人覺得ROCKS面對32 node的小項目是撮撮有余了，另外ROCKS的infiniband Roll和Myrinet Roll都pre-defined得很好. 從我們這些做架構(gòu)的人來說，可能更多考慮系統(tǒng)上的問題，但是最終用戶考慮的是計算，而不是基礎(chǔ)架構(gòu)的問題。所以最小限度的降低工程難度和時間，對雙方來說都是很恰當?shù)摹Ｎ疫@個都是從工程項目角度考慮的，如果是自己玩玩就另當別論了.

個人意見僅供參考，科學計算博大精深，技術(shù)手段不斷進步，選擇合適自己的才是正道.

HonestQiao

終于看完了，強悍啊。

不知道各位對WWW(含數(shù)據(jù)庫)的集群是否有所涉獵