Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Slawa Olhovchenkov

Date

2005-06-01T15:56:04Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Slawa Olhovchenkov wrote:
>  >> У тебя не было приведено ни одного теста где бы двухпроцессорный тазик
>  >> уделал два однопроцессорных. и я догадываюсь почему -- на нынешних процах
>  >> все _очень_ существенно тормозит о память. И чем проц быстрее -- тем это
>  >> больше чувствуется, потому на P3 у тебя и была меньше эта проблема
>  >> заметна -- проц был медленнее, а не чипсет лучше. Поэтому им лучше
>  >> удавалось разделить память. А на частотах под 4ГГц и одному процу
>  >> современной памяти мало, быстродействие-то у нее на случайной выборке
>  >> особенно не выросло.
>  CS> Сходи вот сюда: http://parallel.ru/cluster/leo_performance.html
>  CS> Там есть данные по производительности на один процессор при
>  CS> использовании одного и двух процессоров из узла. И это, еще раз
>  CS> повторяю, на LinPack. Он не очень требователен к латентности среды, хотя
>  CS> на нем это тоже сказывается. К сожалению, не существует настолько же
>  CS> распространенного теста производительности, который был бы критичен
>  CS> именно к этому параметру.
> 
> Вот именно туда я и ходил, после чего и сделал это утверждение.
> Вот покажи пальцем тут http://parallel.ru/cluster/images/perf/cpu4a.gif где два
> проца уделывают два узла?
Э, ну да, теперь я уже белое с черным попутал. Признаю неправоту. 
Видимо, в случае кластера на эзернете сейчас выгоднее использовать 
однопроцессорные узлы.

> Сам же пишешь: "Таким образом, на некоторых тестах ускорение, достигаемое за
> счет использования второго процессора на узле еще меньше, чем на тесте LINPACK,
> а ускорение за счет использования второго процессора на другом узле всегда
> больше."
Ну не совсем я пишу, это текст коллеги из соседней комнаты. Я его 
творчески пересказываю.

>  >>  >> Я думаю на AMD наблюдаются те же соотношения.
>  >>  CS> Забыл винчестеры.
>  >> Нахуа они нужны вообще на счетном кластере?!
>  CS> Для временных файлов. Есть у нас один пользователь-химик. Так вот, у
>  CS> него есть задача, которая так много всего хранит во временных файлах,
>  CS> что при добавлении в узлы кластера второго винчестера она ускорилась
>  CS> примерно в 2,5 раза.
> Стрелять.
Не выходит. Такая задача. Так временных файлов на многие гигабайты.

>  CS> А по NFS это все гонять - можно застрелиться.
> 
> Почему? У гигабита трансыер почти 100МБ/с, у винта меньше.
Так ведь на той стороне тоже винчестер, да еще на который пытаются все 
сразу писать. Это ж какой RAID надо ставить, чтобы обеспечить 
одновременно несколькоим десяткам клиентов такую же скорость, как они со 
своими локальными винтами в сумме.

>  CS> Да и своп бывает. Хоть этого надо повозможности избегать, но бывают не
>  CS> очень хорошо написанные задачи, которые лезут в своп.
> 
> Стрелять. Если кто-то лезет в своп, то своп может кончится. Поэтому будем его
> ликвидировать как класс. Это примерно та же аналогия, что и у кнута была первом
> томе еще: не имеет смысла заниматься перераспределением мелких кусочков
> свободной памяти для получения крупных, поскольку если мы дощли до такого
> состояния то скорее всего очень скоро у нас память вообще кончится.
Тут уже вступают другие соображения, скорее удобства для пользователей.
Есть системные процессы (всякий мониторинг, периодические скрипты и 
т.п.). Держать под них запас свободного ОЗУ - расточительство. А так 
временно вытеснили кусок пользовательской задачи в своп, оно отработало, 
и поехали дальше. Ну или getty всякие в своп уедут.
И еще одно соображение. У нас кластер используется массой разных 
пользователей с разными задачами. И далеко не все из них достаточно 
квалифицированы для такой настройки своих программ. Поэтому из 
политических соображений выгоднее дать этим задачам отсчитаться хоть 
как-то, чем стрелять их. А то начнутся обвинения "у вас ничего не 
работает, задачи падают" и т.п. Если бы кластер был под пару конкретных 
задач, их бы, без сомнения, надо было отлаживать так, чтобы они работали 
без свопа. Кстати, у нас есть система, которая позволяет после отработки 
задачи посмотреть историю использования свопа на тех узлах, где она 
считалась (где считалась задача, берется из системы очередей, которая и 
распределяет задачу по узлам). Так что средства для грамотного 
пользователя предоставлены. Но надо жить и не очень грамотному.

> К сожалению у меня нету возможности это потестировать. Я надеялся что у тебя
> есть. Насколько я был в курсе (могу ошибаться) основное отличие ксенонов от П4
> -- умение вставать парой и более раннее появление всяких модных технологий
> (гипертрединга и прочих).
Увы, у меня тоже тестов нет. может, ты и прав, и разница в названиях - 
очередной маркетинговый ход Интела. Хотя вот вроде как нашел отличие - 
на Xeon максимальный размер кэша больше. Но это так, косметика.

>  >> А про это тебе уже Глеб говрил -- за цену спецкарты можно собрать машину
>  >> на АМД64 и просто удвоить число узлов, чем более чем скомпенсировать
>  >> коэффицент эффективности. Т.е. использование езернета и однопроцессорных
>  >> тазиков позволяет учетверить число узлов, что при том же бюджете может
>  >> позволить удвоить производительность кластера.
>  CS> Еще раз говорю - не на всех задачах.
> 
> Расскажи на каких. То, что две коробки лучше двухголовой -- ты уже сам доказал.
> Почему кластер с коэф. 0.6 и двойным числом узлов будет хуже кластера с коэф.
> 0.8? Даже если у нас будет совсем дерьмо (0.4) мы будем иметь в результате
> аналог 0.8 на половинном числе узлов. А это худший случай, при этом он
> оказывается не хуже альтернативного варианта. А скорее всего будет лучше.
Тут Алексей Семеняка упоминал про задачи с сильно разреженной матрицей, 
которые встречаются у химиков и квантовиков. Я знаю, что на таких 
задачах прирост производительности при добавлении новых узлов сильно 
зависит от латентности среды.
Я уже как-то приводил схему, по которой устроены такие задачи - 
небольшой счет, потом обмен данными, и так по кругу. Если получается, 
что на следующий шаг нельзя идти, не получив данные с предыдущего, то 
начинают сильно влиять характеристики интерконнекта. А если порции 
передаваемых данных невелики (например, обмен данных все ко всем, причем 
от каждого к каждому должно пролететь неколько чисел), то роль ограет 
латентность.
Конкретных задач сходу назвать не могу - надо спрашивать у тех, кто 
такими задачами занимается.

-- 
Константин Стефанов
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 46/50 50/203 520 400/814 450/159 186 247 1024 451/30 461/43 132 640
SEEN-BY: 469/999 550/196 4616/3 4625/8 4627/10 4635/4 4652/15 5000/76 5000
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5015/10 5019/31 5020/52 118 154 175 194
SEEN-BY: 5020/400 545 549 604 715 758 830 937 1057 1523 1604 1630 1922 2020
SEEN-BY: 5020/2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70 72
SEEN-BY: 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1 5060/88
SEEN-BY: 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222 5074/9
SEEN-BY: 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5095/20 5096/18 6000/12 254 6001/3 10

PATH: 5020/400 4441 545 5054/1 37