| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > 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 вычитал это
Кто-нибудь знает, откуда взялось это ограничение и можно ли его обойти (выключить) |
| Автор: bsa 10.9.2012, 16:52 | ||
Ограничение связано в первую очередь с шириной физической шины адреса процессора. Например, у Intel Core 2 Duo:
Добавлено через 1 минуту и 22 секунды Может там вообще кластер будет. Если так, то всю память единым пулом выделить вряд ли получится. |
| Автор: W4FhLF 10.9.2012, 17:12 |
| borisbn, это же система с рапределённой памятью, а не одна рабочая станция. Соответственно и подход совсем другой. По меркам кластеров это вообще скромная машина, инструментарий и средства разработки под такие системы доступны. И вопрос "проверить" совсем не глупый, такие системы покупаются у диллеров, которые должны быть в состоянии обеспечить профессиональную консультацию и ответить на все вопросы касающиеся разработки. borisbn, новые Ivy Bridge поддерживают до 1.5 терабайт на одной шине, но под них ещё платформ по-моему нет. |
| Автор: 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 секунды
хммммммм. А ведь у меня похожая ситуация. Весь пул из 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, 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 |
gcc (на 64х битах) может выделить хоть до полного 64х битного пространства. Сам процессор ограничит до 48 битов (виртуальной). Так что вопрос остается за ОС. |
| Автор: bsa 11.9.2012, 11:01 |
задай их тоже специалистам из означенных контор. А потом нам расскажешь. |
| Автор: tzirechnoy 11.9.2012, 14:14 |
| Спросите у программистов, которые под это писать будут. PS У gcc для amd64 есть полезный ключик -mcmodel=large, он можэт избавить от наступания на некоторые грабли с памятью процэсса большэ 2GiB. Впрочем, грабли нечастые -- в большынстве случаев и без него на 64-битной архитектуре всё заработает. Но вообще проблем с поддержкой линуксом и gcc ожыдается довольно мало. |
| Автор: borisbn 11.9.2012, 14:17 |
Дело в том, что это - я уже знаю. подмимал как-то эту тему - 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, 19:05 | ||||||
Не знаю, я по http://juick.com/[email protected]/2042251 это выяснил. Впрочем, сейчас проверил -- статический массив в 40 тэрабайт вполне можно получить (оверкоммитом, свопа столько нет). Правда, смешно было: компилировался он только при выключенном оверкоммите -- иначе ld успешно получал себе столько памяти, и что-то пытался с ней делать. malloc тожэ на несколько тэрабайт сработал.
При наличии исходников Вы сможэте разбраться, где эти ограничения, и что с ними можно сделать. Кроме того, ограничений можэт и не быть.
Это -- вряд ли. Всё-таки большынство суперкомпьютэрных кластеров работает под линуксом -- и в ядре совсем базовые плюшки, скорее всего, вычистили. |
| Автор: borisbn 11.9.2012, 21:24 |
| tzirechnoy, за ссылку на juick.com спасибо. Познавательно (хотя я и не всё понял) ээээ.... ммммм.... а что такое оверкоммит ? И как его включать/выключать ? |
| Автор: 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 | ||||
Ок. Рассказываю. 1) В IBM меня заверили, что во-первых, этот сервер грубо говоря "прокачанная" рабочая станция. Т.е. речь идёт о том, что все установленные на борту процессоры видят всю память одновременно. Во-вторых, мне сказали, что из линуксов IBM поддерживает Red Hat и SuSe. Если одна из этиз ОС не будут поддерживать этот объём памяти на этом сервере, то это их (АйБиЭмовцев) проблема, которую они будут решать бесплатно 2) Т.к. у нас довольно много наработок на Ubuntu (как наших, так и покупных без исходников), то меня интересовало будет ли работать Ubuntu на таком сервере. В IBM про это не знают, поэтому я связался с Canonical. Вот, что они ответили
Что ж. Осталось мелочь - купить такой сервер за > 4 млн. руб. и проверить P.S. Вот, что значит фирма с мировым именем, продающая что-то и контора, развивающая OpenSource-проект: в IBM мне дали сотовый телефон специалиста, который меня проконсультировал в течение 15..20 минут, ещё и предложив для моих целей более простую модель сервера (мне реально не нужна производительность того сервера, который я нашёл). Canonical же мне вообще не ответила, и мне пришлось общаться с ними через официальных партнёров и заняло это почти 2 недели. |
| Автор: bsa 25.9.2012, 09:58 | ||
А с IBM все просто - им нужно продать свой продукт, вот "жопу и рвут". Кстати, спасибо за информацию. Теперь будем знать. |
| Автор: borisbn 25.9.2012, 20:35 |
| > А с IBM все просто - им нужно продать свой продукт А канониклу не нужно? А после такого отношения не очень-то и хочется и это при том, что пакет "базовый" у них стоит всего 10 Круб в год. Ладно... это уже другая тема. Будет рез-т - отпишусь |