Экономически эффективный способ построить сервер с большим количеством оперативной памяти

Необычные требования иногда выигрывают от необычных решений. Конечно, вы можете дать 6 цифр Sun, Dell или HP и покончить с этим, но это не единственная игра в городе.

Для решений с одной коробкой получение до 128 ГБ очень дешево (32 x 4 ГБ ~ 3 000 долларов США), даже с материнскими платами домашнего производства, которые стоят менее 1 000 долларов США. (Не издевайтесь над создателями. Если это достаточно хорошо для Google...)

256 ГБ серьезно дороже (32x8 ГБ ~ 18 000 долларов США), и помимо этого...

В качестве альтернативы вы рассматривали Infiniband (10 Гбит / с) подключенные дешевые коробки в качестве альтернативы?

Таким образом, вы могли бы построить 4-х узловую, 16-процессорную (64-ядерную) машину объемом 512 ГБ, и при этом все еще иметь изменение от 25000 долларов США.

Кроме того, вы получите дополнительные преимущества постепенной деградации, если ваше приложение может работать на 3 компьютерах, если один из них выйдет из строя, и, возможно, получить линейное масштабирование до 8 узлов (просто добавьте еще 4 узла). В этот момент вы смотрите на крутое 128-ядерное устройство с объемом памяти 1 ТБ за <50 000 долларов США.

Прежде чем отклонить предложение Infiniband как экзотическое, оно не относится к типу машины, о которой вы просите. например, 141 из 500 лучших суперкомпьютеров построен таким образом, включая 4 из 10 лучших ( http://top500.org/connfam/8)

Хорошо, смотри. Вы не найдете сервер с таким объемом ОЗУ, который вам нужен, по крайней мере, сервер, которому не нужна собственная электрическая сеть.

Почему бы не использовать масштабируемый подход и использовать memcached? Вы можете распределить память между различными машинами по сети. Данные никогда не должны касаться дисковода, и с такой сверхбыстрой сетью, которую можно купить за деньги, о которых вы говорите, задержка вряд ли будет проблемой вообще.

Вот клиент memcached для Java: http://www.whalin.com/memcached/

А вот введение в memcached на случай, если вы не знакомы: http://www.danga.com/memcached/

Посмотри на это. Это будет намного более экономически эффективным, чем создание единственной монстровой машины с безумным объемом оперативной памяти. Кроме того, если вы делаете что-то, имеющее такого рода требования, это, вероятно, критически важно, и вам не нужна ни одна точка отказа.

Серверы Opteron с 4 или 8 разъемами, такие как HP DL585 или DL785 или Sun X4600, могут занимать большие объемы памяти в диапазоне 128-256 ГБ. Хотя они не дешевы, они, конечно, не относятся к 6-значным ценникам; 8-полосная 32-ядерная Sun X4600 с 256ГБ списками оперативной памяти стоит около 35000 долларов на их веб-сайте, и это примерно столько же, сколько у этого типа систем. Вы, вероятно, обнаружите, что можете получить систему за несколько меньшую цену, чем указанная на веб-сайте.

Несмотря на то, что доступны 4-гигабитные модули DIMM, они, как правило, стоят с большой ценовой надбавкой, поэтому переход на систему, в которой эти возможности будут максимально эффективными, будет значительно дороже.

Если вы хотите использовать систему такого типа, вам потребуется 64-битная операционная система. Убедитесь, что вы также получили 64-битную JVM и убедитесь, что она хорошо работает с вашим приложением.

Я не буду повторять предложения по аппаратному обеспечению (которые являются правильными), но вы можете посмотреть на Terracotta, чтобы увидеть, подходит ли оно для вашего приложения.

http://www.terracotta.org/

Будьте абсолютно осторожны с такими размерами оперативной памяти. Мы увеличили размер машины HP до 64 ГБ (HP заявила, что она может занимать 128 ГБ), но только после добавления дополнительной переходной платы, охлаждающего вала и т. Д. (После большого разговора с HP).
Только потому, что машина указана для использования до n ГБ, это не значит, что она будет работать без дополнительных изменений. В нашем случае не все нормальные модули памяти работали, потому что они нагрелись, работали только очень специфические модули.

На самом деле у вас есть много вариантов, только из списка HP у вас есть blade-сервер BL680c, который может занимать 128 ГБ, их DL580/585 могут занимать 256 ГБ, а их DL785 - 512 ГБ. Некоторые из IBM занимают 256 ГБ, как и один Dell.

Стоимость оперативной памяти не масштабируется линейно до больших размеров. То, что я могу купить 1 ГБ DIMM за 15 долларов, не означает, что я могу получить сервер с 128 ГБ всего за 1920 долларов... для начала вы не найдете материнскую плату со 128 слотами DIMM.

Выше определенного размера (~8–16 ГБ) вы начинаете видеть материнские платы, требующие полной буферизации модулей DIMM (FB-DIMM), что обойдется вам значительно дороже за ГБ, чем стандартная настольная память.

Мы регулярно используем машины с 128 ГБ памяти, и цена за последние годы значительно снизилась, но у меня нет текущих цифр... и опыта того, насколько хорошо JVM будет масштабироваться до такого объема памяти.,

Типичный способ получить больше системной памяти - получить больше систем. Если память действительно является узким местом, то это не столько объем памяти, сколько у вас есть, но насколько хорошо ваши данные связаны с вашими процессорами. Вам нужно будет масштабировать много вещей, чтобы это принесло вам много пользы.

Для пояснения: простое добавление пары нулей в системную память, вероятно, не приведет к тому, что вы думаете. Что вы обнаружите, так это то, что теперь, когда весь ваш набор данных помещается в память или даже чуть больший ее фрагмент, вы столкнетесь с некоторым другим узким местом, таким как аннулирование кэша.

Правильный способ масштабирования вашей системы - медленно. Если вы сейчас работаете, скажем, на 4-х ядерной системе с 8 гигабайтами оперативной памяти, сначала чертите свое приложение, чтобы увидеть, где на самом деле он проводит время, затем попробуйте увеличить до 12 или 16 гигабайт оперативной памяти и посмотреть, как результаты профилирования изменились.

На самом деле вопрос в том, зачем вам примерно в 100 раз больше системной памяти по сравнению с другими ресурсами, чем обычно доступно. Если ваша схема доступа к данным в некотором роде предсказуема, то, что вы должны сделать, это увеличить пропускную способность диска, этого добьются несколько контроллеров рейда с несколькими чередующимися дисками.

Если ваш шаблон доступа к данным действительно, действительно случайный, то, вероятно, есть место для лучшего оптимизированного алгоритма.

Аналогично предложению FusionIO, вы можете получить устройства, которые позволяют подключать динамическое ОЗУ к интерфейсу SATA. Примерно так (у меня нет опыта работы с продуктом или компанией, это всего лишь первый вариант, который появился в результате поиска в Google Покупках).

Вы можете использовать пару из них в качестве смонтированных файловых систем для кэширования данных с использованием логики вашего приложения (оно питается от батареи, поэтому должно выдержать загрузку и другие сбои), или вы можете использовать их в качестве пространства подкачки и позволить ядру решать, как их использовать (хотя ядра ОС обычно оптимизируются, если предположить, что все области подкачки на несколько порядков медленнее и более латентны, чем реальная оперативная память, тогда это, вероятно, придется значительно настроить, чтобы наилучшим образом использовать такую ​​схему).

Опция FusionIO будет более выгодной, если вам действительно нужно что-то такое большое, такой тип ОЗУ может быть лучше в качестве компромисса. Оценивая, насколько хорошо сервер, способный иметь 128 ГБ ОЗУ на материнской плате, и пару из них с полными заполненными 64 ГБ, сравнивает по цене и производительности со специализированным сервером, поддерживающим 256 ГБ или более, я оставляю это упражнение для читателя!

Будет ли решение Amazon EC2 жизнеспособным для вас? Это, безусловно, будет наиболее экономически эффективным решением.

Через 3 года после вопроса все намного проще.

Я искал некоторые конфиги http://siliconmechanics.com/.

Самый дешевый способ - использовать платформы AMD с 32 диммерами - 512 ГБ - 11,940 $.

Альтернативой, но гораздо более дорогой на ГБ, является платформа Intel с 64 диммами - 1 ТБ - 48,769 $.

Я думаю, вы начнете сталкиваться с проблемами в 64 ГБ на традиционном оборудовании. Если вы сможете масштабироваться оттуда, все будет в порядке, но я предполагаю, что гораздо более экономически эффективным решением было бы подвергнуть сомнению вашу архитектуру. Конечно, я говорю это, не зная, что вы делаете, но я просто выкидываю это туда.

Вам, вероятно, нужен специализированный сервер для этого.

Попробуйте посмотреть на ES7000 от Unisys. Описание там, вероятно, немного устарело.

Он может поддерживать до 512 ГБ оперативной памяти. Он использует хорошо известные O/S, такие как Windows и Linux Enterprise.

Это будет стоить вам ~ 30 тыс. Долл. За стандартную конфигурацию, но с Itanium и всеми прибамбасами он может доходить до ~ 600 тыс. Долл.

С таким большим количеством оперативной памяти вы можете хранить много горячих данных, не затрагивая места на диске вообще.

Я большой поклонник подхода "много дешевых серверов". Рассматривали ли вы, возможно, запуск такого рода процесса на платформе Eucalyptus, доступной в Ubuntu 9.04? Вполне возможно, что вы можете запустить программу такого рода на нескольких компьютерах в их собственной выделенной гигабитной сети с несколькими серверами, работающими на 8, 16 или 32 ГБ ОЗУ, и масштабировать их линейно, добавляя более дешевые серверы, когда они вам нужны.

Как насчет полностью готового решения: базы данных. Я знаю, что вы сказали, что это будет слишком медленно, но это зависит от того, что на нем размещено. Как насчет размещения его на массиве RAID0 достаточно этих.

В Pricewatch 400 долл. За гаджет, чипы стоят по 55 долл. (Я не проверял совместимость) за 4 Гб, так что это еще 440 долл. За память. Это дает вам 32 ГБ за 840 долларов. (Теоретически устройство может принимать 8-гигабитные чипы на общую сумму 64 ГБ, но пока чипы не поддерживаются.)

RAID0 4 из них, и вы находитесь в нижней части диапазона за чуть более 3000 долларов США + обычная коробка. 16 из них получают верхний предел вашего диапазона за $14k.

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

Допустим, вы могли бы разместить столько памяти на сервере (если я не ошибаюсь, Linux на стандартном оборудовании ограничен 64 ГБ, но я не уверен).

В большинстве операционных систем JVM ограничена пространством кучи около 1,4 ГБ-1,6 ГБ, частично потому, что требуется непрерывная память, а частично из-за ограничений операционной системы.

Следовательно, дополнительная оперативная память не поможет вам масштабировать одно приложение, она позволит вам запускать только несколько экземпляров приложения. Однако тогда вам понадобится несколько ядер и возникнут другие проблемы.

Зачем вам столько оперативной памяти? Возможно, вам удастся найти базы данных, которые можно сохранить в памяти или использовать RAM-накопитель, но я не знаю JVM, которая позволила бы вам хранить столько памяти в памяти.

Я прочитал ваш комментарий о характере вашего приложения, но, тем не менее, вы могли бы рассмотреть альтернативные решения.

FusionIO - это реальная альтернатива. Просто взгляни. В 10K $ это все еще намного дешевле чем сервер высокого уровня. Писать пропускную способность 1,0 ГБ / с - это звучит действительно безумно.

Другой вариант - SSD, конечно. На тот случай, если вы видели спецификации для Intel® X25-E Extreme SSD:

Read Latency 75 microseconds
I/O Per Second (IOPS) Random 4 KB reads: >35,000 IOPS
Random 4 KB writes: >3,300 IOPS
Sustained sequential read: up to 250 MB/s
Sustained sequential write: up to 170 MB/s

Помещение их в массив raid 10 может дать вам достаточную производительность. И с 400 долларов США за 32 ГБ, это намного дешевле, чем альтернативные высокопроизводительные серверы.

Очевидно, вам нужны 64-битные операционные системы, но вы не находитесь на территории суперкомпьютера. Например, Dell PowerEdge R900 и R905 доступны с 256 ГБ оперативной памяти и используют простые стандартные процессоры Intel Xeon/AMD Opteron и работают под управлением Linux, Solaris или Windows 2003 и 2008.

Конечно, покупка ОЗУ непосредственно в Dell не очень экономична (они хотят ~35 000 долларов США за 32 x 8 ГБ, а вы можете получить ее уже за 23 000 долларов США, возможно, дешевле), но с другой стороны, вы можете захотеть чтобы обеспечить надлежащую поддержку, если вы покупаете сервер за 40 000 долл. (вы не ожидали, что 256 ГБ ОЗУ будут дешевыми, не так ли? Если и 128 ГБ тоже в порядке, вы можете сэкономить ~12 000 долл.).

У меня нет опыта, какую операционную систему выбрать, хотя запуск 100+ ГБ Java обычно не то, что я делаю:)