Комментарии 76
16x128=2Тб памяти (на более-менее хорошей серверной материнке). Уже лучше, хотя всё ещё маловато.
Маловато для чего? Я столько вкладок в браузере не открою…
Пока что не откроете. Кроме того, речь про сервера. А уж чем на сервере 2Тб забить… select *… inner join… outer join… inner join… outer join… И так пока памяти хватит.
если начать открывать прямо сейчас, то наверно можно (:
Ха! Скажете это года через 3-4: ребята-браузеростроители не сидят на месте! )
И это — самое грустное.
Это еще не страшно.
Вот когда будет перестанет хватать 2Тб L1-кэша на камне — вот тогда да, можно будет начинать панику :)
Вот когда будет перестанет хватать 2Тб L1-кэша на камне — вот тогда да, можно будет начинать панику :)
Если это случится — я паяльником выну гигабайтный регистровый файл из процессора и спаяю на нем свой компьютер для Fido.
Регистровый файл?
Знаете, что такое регистры процессора? Это очень дорогая и маленькая память. У x86_64 — шестнадцать регистров «общего назначения», доступных программе. Но реально их больше, так как есть такая фитча, как переименование регистров, нужная для суперскалярности. Кусок процессора, занятый под эти регистры и называется регистровым файлом.
Не то слово((
для Duke Nukem в стиме рекомендованные требования: 1 гиг оперативы, 256 видео и процессор 1,8 ГГц
store.steampowered.com/app/225140/?snr=1_237_151__103_2
store.steampowered.com/app/225140/?snr=1_237_151__103_2
Ну, это ж на сокет =))
А так на 2 сокета и сейчас можно 2TiB набить.
А так на 2 сокета и сейчас можно 2TiB набить.
На ещё чуть более хорошей серверной материнке слоты ОЗУ находятся на платах расширения, и слотов получается сильно больше 16. Ещё есть QPI, а IBM делал полки с ОЗУ.
Объём ОЗУ одного сервера ограничен бюджетом, а не техникой.
Объём ОЗУ одного сервера ограничен бюджетом, а не техникой.
Сейчас на рынке даже нет материнских плат, которые бы поддерживали 128 Гб на один слот памяти.
Всегда думал, что зависит это от ЦП, а не от матери.
И да, уже есть материнские платы с DDR4?
Может имеется ввиду что нет соответствующих плат, куда бы можно было вставить эту планку? Процессор процессором, но не молотком же их забивать.
там 288-контактные разъём, таких плат просто пока нет, в DDR3/2 было 240.
Нынешние процессоры x86_64 могут адресовывать до 16 Эксабайт (порядка 16 000 000 000 гигабайт).
Наличие 64-битной адресации не означает возможность хоть как-то такое количество памяти к процессору подключить. Почитайте datasheet на 23-24 страницах. Там предъявляются вполне конкретные требования к поддерживаемой памяти.
Увы, это все виртульная память. Физическая зависит от шины процессора\матплаты\ОС.
Таких пару штук в сервер, сам сервер — в мощный УПС и можно хранилище делать для супер-высоконагруженных проектов и сервисов. Типа Gigabyte RAM-drive, только штатными средствами.
Похоже можно винт и не покупать, все будет в памяти храниться.
С такими то объёмами почти все можно хранить в ОЗУ, только бекапы периодически писать на диск.
Совмещать такие модули с SSD, получив новый тип гибридных накопителей. В процессе работы держать все в ОЗУ. Красота.
Ура… мы летим в космос :)
НЛО прилетело и опубликовало эту надпись здесь
А что же произойдет в случаи системного сбоя? Kernel Panic или того хуже BSoD? Для таких решений нужна реализация низкоуровневой прослойки которая будет разгребать что же система оставила в оперативке, куда и как это записывать, или же бекапить ОЗУ в swap раздел, и потом колупать ее с вновь запущенной системы в поисках того, что же там было и не записано в фс на винте…
Железные RAM drive в виде платы с аккумулятором для слота PCI давным давно придумали.
НЛО прилетело и опубликовало эту надпись здесь
Обычные DRAM требует постоянной регенерации. Помимо самой памяти, надо еще и контроллеры питать. Потребуются сравнительно емкие аккумуляторы. А значит и объемные. И то при долгом выключении все пропадет. Нужно либо энергонезависимое ОЗУ, либо ПЗУ, имеющее объем, сравнимый с используемым ОЗУ, в которое будет закидываться содержимое ОЗУ при отсутствии питания. При последнем варианте аккумулятора должно хватать лишь не небольшой промежуток времени, требующийся для копирования.
> 128 ГБ
> Он базируется на 8 гигабитных чипах DDR3
По моим подсчетам, для этого надо 128 чипов, но на картине их явно меньше, даже если предположить, что они там с двух сторон.
> Он базируется на 8 гигабитных чипах DDR3
По моим подсчетам, для этого надо 128 чипов, но на картине их явно меньше, даже если предположить, что они там с двух сторон.
И да, мне было интересно, «на восьми гигабитных» или там опечатка и «на восьмигигабитных». Восемь гигабитных дают гигабайт. А восьмигигабитных надо 128. Странно как-то.
<sarcasm>Они ещё красиво расположили чипы на плате. Расово верно, я бы сказал.</sarcasm>
И вообще почему DDR3, если это DDR4? :)
А так на фотке вижу только на 1 стороне 18 чипов + 1 ECC, но 128 ни на 18 ни на 36 ровно не делится.
А так на фотке вижу только на 1 стороне 18 чипов + 1 ECC, но 128 ни на 18 ни на 36 ровно не делится.
При таком расположении на обратной стороне вместо ecc+spd может влезть ещё 2 чипа, но 38 — тоже не круглое число.
Возможно там действительно 8Гбайт микрухи, а 2 лишние используются как резерв. На нынешних модулях серверных тоже есть возможность отключения сбойного чипа и перенос его функций на ECC чип (с отключением ецц ессесно).
Может тут что-то в таком духе, аля избыточный объем как в SSD.
Может тут что-то в таком духе, аля избыточный объем как в SSD.
К сожалению на сайте skhynix я этих чипов не нашел. Западный интернет рассказывает повально про 8Gb чипы.
Судя по www.businesskorea.co.kr/article/3977/12gb-dram-sk-hynix-develops-world%E2%80%99s-first-128gb-ddr4-memory-chip на double side dimm упаковали 64GB. При той же упаковке с использование though silicon via (слойка из чипов в одном корпусе удалось уплотнить в два раза.
36 чипов соответствует 9*4 (по чипу для ecc на каждый байт) что при чипах в 2GB (16Gb) даст как раз 64GB. А при соответствующем уплотнении может дать 128GB.
Самые последние серийные DDR4 чипы, например, самсунга имеют плотность 8Gb. Вариант компоновки, схожий с представленным на фотов посте можно увидеть тут: www.samsung.com/global/business/semiconductor/file/product/DDR4_Product_guide_Dec13.pdf.
См LRDIMM.
Комментарий уже нечаяно отправил, поэтому оставлю с минимальными дополнениями.
Судя по www.businesskorea.co.kr/article/3977/12gb-dram-sk-hynix-develops-world%E2%80%99s-first-128gb-ddr4-memory-chip на double side dimm упаковали 64GB. При той же упаковке с использование though silicon via (слойка из чипов в одном корпусе удалось уплотнить в два раза.
36 чипов соответствует 9*4 (по чипу для ecc на каждый байт) что при чипах в 2GB (16Gb) даст как раз 64GB. А при соответствующем уплотнении может дать 128GB.
Самые последние серийные DDR4 чипы, например, самсунга имеют плотность 8Gb. Вариант компоновки, схожий с представленным на фотов посте можно увидеть тут: www.samsung.com/global/business/semiconductor/file/product/DDR4_Product_guide_Dec13.pdf.
См LRDIMM.
Комментарий уже нечаяно отправил, поэтому оставлю с минимальными дополнениями.
Новый модуль также представляет собой модуль с самым плотным в мире размещением компонентов. Он базируется на 8 гигабитных чипах DDR3
Что-то тут не так наверное?
128 GB в руках, а ногти не стрижены ;(
17 гигабит в сек для 128гигабайтного модуля… это прочитать весь модуль займёт целую минуту! где же ты hybrid memory cube…
Маст хэв всем java программистам
это in-memory продукты, решения для редактирования больших объемов графики и видео и...
...Google Chrome
Мне одному думается, что, скажем, Samsung возможно обломает планы SK Hynix на «дорогой и нишевый продукт»?
А зачем? Зачем нормальному человеку 128 гигабайт на десктопе — тем более одной планкой? 64 гигабайт хватит всем.
Билли как-то долго всем доказывал, что 64 Кб хватит всем.
А давно ли на десктопе используют registred ecc memory?
Вот и я о том же — в десктопы этот монстр не пойдет. Надеюсь — никогда.
У меня на ноуте 16G и мне бывает мало. А больше проц не поддерживает =(
А как вы эти 16G используете?
1-2 виртуалки в vagrant или аппсервер, несколько бд, небольшой tmpfs, idea/rubymine (обычно несколько экземпляров), браузер.
Например, сейчас у меня запущены: 1 виртуалка в vagrant, idea, pycharm, mongodb, rabbitmq, chrome, docker. Всего счастья на 12G. Но я давно вкладки лишние не закрывал ,)
В обычной работе занято 8-14G, остальное — дисковые кэши (та же mongodb их любит). Иногда забивается полностью, но стараюсь не доводить. Последнее время больше упирается в ssd и cpu.
Например, сейчас у меня запущены: 1 виртуалка в vagrant, idea, pycharm, mongodb, rabbitmq, chrome, docker. Всего счастья на 12G. Но я давно вкладки лишние не закрывал ,)
В обычной работе занято 8-14G, остальное — дисковые кэши (та же mongodb их любит). Иногда забивается полностью, но стараюсь не доводить. Последнее время больше упирается в ssd и cpu.
Но это — практически сервер, а я все-таки говорю о десктопах.
Это не сервер. В лучшем случае мобильная рабочая станция, хотя ноут — обычный lenovo x220. И то, на рабочих станциях обычно уже используют registred ecc memory.
Все вещи, которые на нем используются — dev environment, не более
Все вещи, которые на нем используются — dev environment, не более
По нагрузке это ближе к серверу. И почему вы не хотите вынести такие вещи, как, например, mongodb, на стационарную систему? Мне кажется, это сильно упростило бы жизнь.
Чем упростило бы?
На локальной машине можно спокойно гонять тесты в монге, убивать коллекции и базы и т. п. Плюс меньше затрат на сетевой стек, что приятно сказывается на времени тестирования. Использовать монгу на сервере мне актуально только при значительном объеме тестовых данных (больше нескольких ГБ, когда ssd становится жалко =) ), но там нужна аккуратность. Держать рядом dev и stage/production — опасно. Иметь отдельный сервер под dev — избыточно.
Тестировать деплой и интеграционку в vagrant, закидывая туда даже жалкие 200-300 MB (не считая того, что тащится из репозитория), куда дешевле на локальной машине.
Локальная отладка в аппсервере или сервлет-контейнере куда удобнее, чем удаленная. Просто по скорости.
Отгружать сборку своих проектов на сервер — не разумно. Они локально вполне нормально собираются за десятки секунд. Пушить в git или гонять rsync только ради сборки на сервере смысла нет, т. к. лишние операции.
В общем, не вижу никаких проблем в том, чтобы использовать нормальный ноутбук на жалком sandy i5 в качестве workstation. Причин перетаскивать dev окружение на отдельную машину — тоже. Учитывая, что администрирование всего этого хозяйства тоже на мне — нафиг такое счастье.
Повторюсь, по нагрузке это не дотягивает до нормальной рабочей станции. Про нормальные сервера — вообще молчу.
На локальной машине можно спокойно гонять тесты в монге, убивать коллекции и базы и т. п. Плюс меньше затрат на сетевой стек, что приятно сказывается на времени тестирования. Использовать монгу на сервере мне актуально только при значительном объеме тестовых данных (больше нескольких ГБ, когда ssd становится жалко =) ), но там нужна аккуратность. Держать рядом dev и stage/production — опасно. Иметь отдельный сервер под dev — избыточно.
Тестировать деплой и интеграционку в vagrant, закидывая туда даже жалкие 200-300 MB (не считая того, что тащится из репозитория), куда дешевле на локальной машине.
Локальная отладка в аппсервере или сервлет-контейнере куда удобнее, чем удаленная. Просто по скорости.
Отгружать сборку своих проектов на сервер — не разумно. Они локально вполне нормально собираются за десятки секунд. Пушить в git или гонять rsync только ради сборки на сервере смысла нет, т. к. лишние операции.
В общем, не вижу никаких проблем в том, чтобы использовать нормальный ноутбук на жалком sandy i5 в качестве workstation. Причин перетаскивать dev окружение на отдельную машину — тоже. Учитывая, что администрирование всего этого хозяйства тоже на мне — нафиг такое счастье.
Повторюсь, по нагрузке это не дотягивает до нормальной рабочей станции. Про нормальные сервера — вообще молчу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первый 128-гигабайтный DDR4-модуль памяти Hynix