Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Программирование под Unix/Linux > 2 TB ОЗУ. Как заюзать


Автор: borisbn 10.9.2012, 15:09
Здравствуйте.
Стоит такая задача: заюзать в программе 1,6 ТБ ОЗУ.
Вопрос:
1) какая ОС из семейства линукс вообще поддерживает
2) есть ли какие-нибудь ограничения по памяти в gcc

Вопросы типа "а проверить" просьба не задавать, т.к. http://www-03.ibm.com/systems/ru/x/hardware/enterprise/x3850x5/ стоит недёшево, а купить его и убедиться, что либо ОС либо компилятор его не поддерживают - это EPIC FAIL.

Спасибо

Добавлено через 8 минут и 16 секунд
https://help.ubuntu.com/community/32bit_and_64bit вычитал это
Цитата
A 64-bit computer will be able to address up to 16.8 million TB (16 exabytes) although constraints are in place that limit this to around 1TB.

Кто-нибудь знает, откуда взялось это ограничение и можно ли его обойти (выключить)

Автор: bsa 10.9.2012, 16:52
Ограничение связано в первую очередь с шириной физической шины адреса процессора. Например, у Intel Core 2 Duo:
Код
address sizes    : 36 bits physical, 48 bits virtual
Как не трудно догадаться физически адресовать может 32 ГБ, в то время, как виртуальная позволяет адресовать аж 256 ТБ. Поэтому, сначала узнай, какая шина у процессора в том сервере. И вообще, что за архитектура там?

Добавлено через 1 минуту и 22 секунды
Может там вообще кластер будет. Если так, то всю память единым пулом выделить вряд ли получится.

Автор: W4FhLF 10.9.2012, 17:12
borisbn, это же система с рапределённой памятью, а не одна рабочая станция. Соответственно и подход совсем другой. По меркам кластеров это вообще скромная машина, инструментарий и средства разработки под такие системы доступны. И вопрос "проверить" совсем не глупый, такие системы покупаются у диллеров, которые должны быть в состоянии обеспечить профессиональную консультацию и ответить на все вопросы касающиеся разработки. 

borisbn, новые Ivy Bridge поддерживают до 1.5 терабайт на одной шине, но под них ещё платформ по-моему нет.

Автор: borisbn 10.9.2012, 17:29
Цитата(bsa @  10.9.2012,  16:52 Найти цитируемый пост)
 И вообще, что за архитектура там?

Цитата
Двух- или четырехпроцессорный корпоративный сервер на базе процессоров Intel Xeon

Цитата
Возможность масштабирования от 2-процессорных сокетов и 2 модулей DIMM до 8-процессорных сокетов и 128 модулей DIMM (при использовании двух систем)


W4FhLF, честно говоря, никак не соображу, кластер это или "прокачанный" сервер.

Цитата(W4FhLF @  10.9.2012,  17:12 Найти цитируемый пост)
такие системы покупаются у диллеров, которые должны быть в состоянии обеспечить профессиональную консультацию и ответить на все вопросы касающиеся разработки

Уже. Сегодня связался с IBM, но, боюсь, выяснение нужных мне "программистких" вопросов может занять длииииительное время, а у нас (как частенько бывает в РФ) срок - вчера. Поэтому и решил распараллелить выяснение: и у диллеров и на форуме.

В любом случае, спасибо.

Цитата(W4FhLF @  10.9.2012,  17:12 Найти цитируемый пост)
инструментарий и средства разработки под такие системы доступны.

А вот этого очень не хотелось бы. Дело в том, что программа уже имеется, и мне хотелось бы тупо изменить пару дефайнов (умножить на 100) и всё. Звучит как-то по-детски "тупо изменить пару дефайнов", но... почему бы и нет ?

Автор: bsa 10.9.2012, 17:35
borisbn, смотри, будет у тебя 4-х процессорный сервер. Допустим, каждый процессор будет владеть 512 ГБ личного ОЗУ. В пределах нее объема доступ к памяти быстрый, но как только процессор пытается влезть в память соседа, то скорость снижается у обоих, так как сосед должен прерваться, прочитать данные, и отдать их...
Я не специалист по таким машинам, но читал про организацию взаимодействия.

Автор: borisbn 10.9.2012, 17:35
Есть ещё одно http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF05a/3709945-3709945-3328410-3722793-3722793-4268690.html?dnr=1
Там указывается ОС - Windows Server 2008. Windows нам не подходит, но сам факт, что туда ставится обычная (ну, ладно... не совсем обычная) ОС даёт надежду, что программам можно будет выделять до 2 ТБ памяти.
Или эта надежда не обоснована ?

Добавлено через 6 минут и 3 секунды
Цитата(bsa @  10.9.2012,  17:35 Найти цитируемый пост)
Допустим, каждый процессор будет владеть 512 ГБ личного ОЗУ. В пределах нее объема доступ к памяти быстрый

хммммммм. А ведь у меня похожая ситуация. Весь пул из 1,5 ТБ единым куском мне не нужен. У меня создаётся кол-во потоков по кол-ыу ядер и каждое ядро работает со своим куском. Сейчас этот кусок находится на HDD, а мы планируем его загрузить в память и одновременного доступа из разных потоков к одной памяти (о котором Вы говорили) не должно быть.
Однако вопрос остаётся.
Сможет ли Ubuntu увидеть 2 ТБ ?
Сможет ли gcc выделить если не единым блоком, а по 32 ГБ, но в сумме 2 ТБ ?

Автор: W4FhLF 10.9.2012, 17:57
Мне кажется вы что-то путаете тут. Всё-таки нужна система с разделяемой или распределённой памятью? Приложения с распределённой памятью имеют принципиально другую парадигму программирования. Никакие потоки тут больше не "работают" и дело не в том, что доступ медленный, это просто невозможно. Стандартом де-факто для таких систем являются протоколы обмена сообщениями на базе MPI и работа осуществляется с множеством процессов, каждый имеет свою независимую память. Физически такая машина это набор отдельных PC, которые соединены  высокоскоростным каналом (Infiniband обычно). 

Автор: borisbn 10.9.2012, 18:00
Цитата(W4FhLF @  10.9.2012,  17:57 Найти цитируемый пост)
Всё-таки нужна система с разделяемой или распределённой памятью? 

Насколько я понял из Вашего описания распределённой памяти, мне нужна разделяемая. Т.е. я фактически хочу масштабировать имеющуюся программу на больший объём памяти.

Автор: W4FhLF 10.9.2012, 18:06
В таком случае вам нужна просто прокачанная рабочая станция типа такой: http://www.hp.com/united-states/campaigns/workstations/index.html

Как я уже писал, в ближайший год можно ожидать системы с большим объёмом памяти в связи с выходом новых архитектур процессоров, но сейчас больше 512 Гб найти будет трудно наверное. 

Автор: bsa 10.9.2012, 23:11
W4FhLF, у HP максимум 512 ГБ. А тут речь идет о 2 ТБ оперативной памяти.

Автор: borisbn 11.9.2012, 06:27
Господа, если предположить, что проблема с "железом" решена (вернее, скажем так - я её беру на себя - свяжусь с HP, IBM etc.), то как насчёт моих вопросов по ОС и гцц?

Автор: xvr 11.9.2012, 06:50
Цитата(borisbn @  11.9.2012,  06:27 Найти цитируемый пост)
то как насчёт моих вопросов по ОС и гцц?

gcc (на 64х битах) может выделить хоть до полного 64х битного пространства. Сам процессор ограничит до 48 битов (виртуальной). Так что вопрос остается за ОС. 

Автор: bsa 11.9.2012, 11:01
Цитата(borisbn @  11.9.2012,  07:27 Найти цитируемый пост)
как насчёт моих вопросов по ОС и гцц? 

задай их тоже специалистам из означенных контор.  smile 
А потом нам расскажешь. smile

Автор: tzirechnoy 11.9.2012, 14:14
Спросите у программистов, которые под это писать будут.

PS У gcc для amd64 есть полезный ключик -mcmodel=large, он можэт избавить от наступания на некоторые грабли с памятью процэсса большэ 2GiB. Впрочем, грабли нечастые -- в большынстве случаев и без него на 64-битной архитектуре всё заработает. Но вообще проблем с поддержкой линуксом и gcc ожыдается довольно мало.

Автор: borisbn 11.9.2012, 14:17
Цитата(tzirechnoy @  11.9.2012,  14:14 Найти цитируемый пост)
Спросите у программистов, которые под это писать будут.

Дело в том, что это - я  smile 

Цитата(tzirechnoy @  11.9.2012,  14:14 Найти цитируемый пост)
У gcc для amd64 есть полезный ключик -mcmodel=large

уже знаю. подмимал как-то эту тему - http://forum.vingrad.ru/forum/topic-353079/view-all.html - в самом конце сам же себе ответил.

Всё равно спасибо, что откликнулись. 

Автор: tzirechnoy 11.9.2012, 14:52
Цитата
в самом конце сам же себе ответил.


А, я действительно пропустил окончание той темы.
Но, надо заметить, что несмотря на то, что в info gcc у меня тожэ это написано -- -mcmodel=large работает как полагается.

Добавлено через 1 минуту и 57 секунд
А вообще, можно позаимствовать у кого-нибудь пару тэрбайтных винтов, создать своп и проверить. Правда, полный проход будет долгим, ну тут уж что поделаешь.

Автор: bsa 11.9.2012, 15:39
tzirechnoy, не обязательно проходить полностью. Имхо, достаточно просто выделить столько и записать/прочитать в нескольких случайных местах, а так же в начале и конце блока. Если память выделится (а линукс известен своим оптимизмом на этот счет), и при этом программа не свалится по сегфолту, то можно считать, что скорее всего проблем не будет.

Автор: borisbn 11.9.2012, 15:40
Цитата(tzirechnoy @  11.9.2012,  14:52 Найти цитируемый пост)
-mcmodel=large работает как полагается

какой максимальный размер памяти удавалось выделить ?

Цитата(tzirechnoy @  11.9.2012,  14:52 Найти цитируемый пост)
А вообще, можно позаимствовать у кого-нибудь пару тэрбайтных винтов, создать своп и проверить

Это-то не проблема (найти пару ТБ винтов), но есть опасения, что при любом исходе этого эксперимента я не получу гарантию, что с настоящим ОЗУ будет то же самое. В самой подсистеме свопирования могут быть ограничения (вариант, что не заработало) или подсистема работы с ОЗУ может работать с такими объёмами только со свопом, а физического объёма не увидит в принципе...

Хотя, проверить всё же стОит. Спасибо за наводку

Автор: tzirechnoy 11.9.2012, 19:05
Цитата
какой максимальный размер памяти удавалось выделить ?


Не знаю, я по http://juick.com/[email protected]/2042251 это выяснил.
Впрочем, сейчас проверил -- статический массив в 40 тэрабайт вполне можно получить (оверкоммитом, свопа столько нет). Правда, смешно было: компилировался он только при выключенном оверкоммите -- иначе ld успешно получал себе столько памяти, и что-то пытался с ней делать.
malloc тожэ на несколько тэрабайт сработал.

Цитата
В самой подсистеме свопирования могут быть ограничения (вариант, что не заработало)


При наличии исходников Вы сможэте разбраться, где эти ограничения, и что с ними можно сделать. Кроме того, ограничений можэт и не быть.

Цитата
или подсистема работы с ОЗУ может работать с такими объёмами только со свопом,


Это -- вряд ли. Всё-таки большынство суперкомпьютэрных кластеров работает под линуксом -- и в ядре совсем базовые плюшки, скорее всего, вычистили.

Автор: borisbn 11.9.2012, 21:24
tzirechnoy, за ссылку на juick.com спасибо. Познавательно (хотя я и не всё понял)

Цитата(tzirechnoy @  11.9.2012,  19:05 Найти цитируемый пост)
оверкоммитом, свопа столько нет

Цитата(tzirechnoy @  11.9.2012,  19:05 Найти цитируемый пост)
при выключенном оверкоммите

ээээ.... ммммм.... а что такое оверкоммит ? И как его включать/выключать ?

Автор: tzirechnoy 11.9.2012, 23:35
Цитата
ээээ.... ммммм.... а что такое оверкоммит ? И как его включать/выключать ?


Выделение адресного пространства, под которое нет места ни в физической, ни в виртуальной памяти.
/proc/sys/vm/overcommit_memory
(0 -- какая-то эвристика, отвергающая только совсем невменяемые запросы. 1 -- все запросы удовлетворяются. 2 -- система считает, что у неё есть total_swap+total_ram*overcommit_ratio/100 памяти. Соответственно, если overcommit_ration < 100 -- то выделенная память всегда имеется в наличии)
/proc/sys/vm/overcommit_ratio


Автор: borisbn 24.9.2012, 16:10
Цитата(bsa @  11.9.2012,  11:01 Найти цитируемый пост)
задай их тоже специалистам из означенных контор.   
А потом нам расскажешь.  

Ок. Рассказываю.
1) В IBM меня заверили, что во-первых, этот сервер грубо говоря "прокачанная" рабочая станция. Т.е. речь идёт о том, что все установленные на борту процессоры видят всю память одновременно. Во-вторых, мне сказали, что из линуксов IBM поддерживает Red Hat и SuSe. Если одна из этиз ОС не будут поддерживать этот объём памяти на этом сервере, то это их (АйБиЭмовцев) проблема, которую они будут решать бесплатно
2) Т.к. у нас довольно много наработок на Ubuntu (как наших, так и покупных без исходников), то меня интересовало будет ли работать Ubuntu  на таком сервере. В IBM про это не знают, поэтому я связался с Canonical. Вот, что они ответили
Цитата
   I just heard back from Darryl about this and the verdict is that it
*should* in principle support 2TB of physical RAM because a 64-bit kernel
can *in theory* support up to 128TB of RAM.

   However I should point out that Canonical has not tested this in any 
configuration as far as we're aware and so as we have not verified this 
in practice we cannot guarantee anything.

   If it does not work though then this would be a bug and it could be 
fixed by us (so long as the customer has Ubuntu Advantage of course) so 
long as there were no hardware limitations and the hardware is fully 
supported.

Что ж. Осталось мелочь - купить такой сервер за > 4 млн. руб. и проверить  smile 

P.S. Вот, что значит фирма с мировым именем, продающая что-то и контора, развивающая OpenSource-проект:
в IBM мне дали сотовый телефон специалиста, который меня проконсультировал в течение 15..20 минут, ещё и предложив для моих целей более простую модель сервера (мне реально не нужна производительность того сервера, который я нашёл).
Canonical же мне вообще не ответила, и мне пришлось общаться с ними через официальных партнёров и заняло это почти 2 недели.

Автор: bsa 25.9.2012, 09:58
Цитата(borisbn @  24.9.2012,  17:10 Найти цитируемый пост)
Canonical же мне вообще не ответила, и мне пришлось общаться с ними через официальных партнёров и заняло это почти 2 недели. 
Ты у них платную поддержку покупал? Если нет, то с какого бодуна они должны с тобой разговаривать? Просто "халявщиков" много, а бесплатно отвечать на их вопросы далеко не каждый может себе позволить.
А с IBM все просто - им нужно продать свой продукт, вот "жопу и рвут".

Кстати, спасибо за информацию. Теперь будем знать.

Автор: borisbn 25.9.2012, 20:35
> А с IBM все просто - им нужно продать свой продукт
А канониклу не нужно? А после такого отношения не очень-то и хочется
и это при том, что пакет "базовый" у них стоит всего 10 Круб в год.
Ладно... это уже другая тема. Будет рез-т - отпишусь 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)