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

Вопросы типа "а проверить" просьба не задавать, т.к. такой сервер  стоит недёшево, а купить его и убедиться, что либо ОС либо компилятор его не поддерживают - это EPIC FAIL.

Спасибо

Добавлено через 8 минут и 16 секунд
Здесь вычитал это

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

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

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

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

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

Это сообщение отредактировал(а) W4FhLF - 10.9.2012, 17:13

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


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

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


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

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

Есть ещё одно решение от HP
Там указывается ОС - Windows Server 2008. Windows нам не подходит, но сам факт, что туда ставится обычная (ну, ладно... не совсем обычная) ОС даёт надежду, что программам можно будет выделять до 2 ТБ памяти.
Или эта надежда не обоснована ?

Добавлено через 6 минут и 3 секунды

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

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

Это сообщение отредактировал(а) W4FhLF - 10.9.2012, 17:59

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

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

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

Это сообщение отредактировал(а) W4FhLF - 10.9.2012, 18:08

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

Не знаю, я по другой причине это выяснил.
Впрочем, сейчас проверил -- статический массив в 40 тэрабайт вполне можно получить (оверкоммитом, свопа столько нет). Правда, смешно было: компилировался он только при выключенном оверкоммите -- иначе ld успешно получал себе столько памяти, и что-то пытался с ней делать.
malloc тожэ на несколько тэрабайт сработал.



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



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

tzirechnoy, за ссылку на juick.com спасибо. Познавательно (хотя я и не всё понял)



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

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

Ок. Рассказываю.
1) В IBM меня заверили, что во-первых, этот сервер грубо говоря "прокачанная" рабочая станция. Т.е. речь идёт о том, что все установленные на борту процессоры видят всю память одновременно. Во-вторых, мне сказали, что из линуксов IBM поддерживает Red Hat и SuSe. Если одна из этиз ОС не будут поддерживать этот объём памяти на этом сервере, то это их (АйБиЭмовцев) проблема, которую они будут решать бесплатно
2) Т.к. у нас довольно много наработок на Ubuntu (как наших, так и покупных без исходников), то меня интересовало будет ли работать Ubuntu  на таком сервере. В IBM про это не знают, поэтому я связался с Canonical. Вот, что они ответили

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

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

Ты у них платную поддержку покупал? Если нет, то с какого бодуна они должны с тобой разговаривать? Просто "халявщиков" много, а бесплатно отвечать на их вопросы далеко не каждый может себе позволить.
А с IBM все просто - им нужно продать свой продукт, вот "жопу и рвут".

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

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