|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 17 Apr 2001 17:30:41
To : "Serge A. Suchkov"
Subject : Re: оффтопик на гране кластеров
--------------------------------------------------------------------------------
Hi, Serge!
>>>>> "SAS" == Serge A Suchkov <ss@e1.bmstu.ru> writes:
>> что гораздо эфективнее сделать толстый сервер, и всех пускать через
>> него, чем несколько маленьких. Это позволит сэкономить на "балансеровки
>> нагрузки".
SAS> Я например нефига не пойму, что мне удасться "сбалансировать" в
SAS> задачке которой сколько процессора не дашь она все схавает и добавки
SAS> быстренько попросит
то, что средняя производительность выше. Т.е. ты будешь или получать выше
пиковую, или будет меньше время на "обсулживание", при том-же потоке
задачь.
SAS> повторю тезис:
SAS> 1) Серверная модель беcсмысленна для тупой числодробильной задачи
SAS> (одной) как таковой.
У тебя все сервера просессоры с постоянной нагрузкой? Все время? Есть
непрерывный поток задач для _каждого+ из процессоров, и он простояно их
молотит?
пойми, теория вероятности хорошо работает на больших числах. Все что
"среднее" - это ТВ. Т.е. чем больше у тебя поток задачь, и чем более
производительный сервер, тем точнее ты сможешь очень затраты.
SAS> 2) По $$ соображениям сейчас выгоднее под одну задачу иметь одну
SAS> машину
да? А по ночам гонять rc5des на ней?
Просто даже тупое сваливание "всех на один крей" может дать _с_среднем_
экономию в деньгах. цена железяки растет нелинейно с ценой ее
производительности.
>> Я уже тут говорил, что собрать простенький кластерок на линуксах будет
>> стоить ооочень немного. И именно на вычилслительных задачах это будет
>> очень эфективное вложение денег, потому как не нужно будет заказывать
>> редкое железо, а можно набрать всяких интегрировных материнок, с двумя
>> слотами для памяти и одним процессором.
SAS> Кластеры это "совсем другая история" потому как не все так уж и
SAS> гладко ложится на распределенную архитектуру но с точки зрения
SAS> эффективности (вычислитильная мощность/$) это _сейчас_ одно из
SAS> наиболее оптимальных решений ...
в данном случае, имелось в виду, что для конкретного человека со счетной
задачей совершенно всеравно на чем там она считается. Ему важно время,
которое понадобится на получение результата.
Если Sun/IBM/Cray/SGI стоили денег соизмеримый с cluster(x86) - то
"нэма базара!". Покупается Крей - и не нам гоняются числа. Hо это все там
внутри.
Иметь один мощьный "автомат облуживания", и "один поток заданий" гораздо
проще, для выяснения эфективности, и так длаее, нежели "много разных
автоматов, и много потоков задач". Их просто сложнее анализировать и
оптимизировать.
>> Да, но разговор то был о том, что не втыкается все что хочется.
>> А втукается туда, что стоит уже несколько других денег..
SAS> Hу это вопрос сложный потому как железяка за $15k от железяки в $1.5k
SAS> на МОЙ вкус отличаются весьма слабо ... вот только под первую
SAS> придется программить побольше потому как она, ясный пень, SMP ... а
SAS> реальная производительность первой будет больше раза в 2 от силы
SAS> (если вообще будет больше :))
Дело не во вкусе. Дело вот в тех самых счетах для тех самых бухгалтеров.
"Железяка" в $15K сможет делать больше, чем 10 железяк в $1.5K.
даже если она "внутри" будет именно из этих 10 железяк и состоять.
Учитывая то, что рост производительности нелинейный, выигрышь
достигается в более простом анализе и распределении нагрузки. И плюс,
конечно пиковая производительность повыше.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
