많은 RAM으로 서버를 구축하는 비용 효율적인 방법


10

확장 성이 주로 RAM으로 제한되는 Java 응용 프로그램이 있는데 데이터 센터의 하나 이상의 서버에서 실행하고 싶습니다. 100GB-512GB 이상의 RAM을 수용 할 수있는 서버 하드웨어를 어디에서 찾아야합니까? 나는 그런 문제에 대한 전문가가 아니므로 어디서부터 시작 해야할지 정말로 모른다.

이것이 슈퍼 컴퓨터 영역에 들어가고 있습니까 (6 자리 이상), 또는 5 자리의 적은 금액으로 그러한 서버를 얻을 수 있습니까?

아래 몇 가지 질문에 근거한 몇 가지 참고 사항 :

  • 예,이 확장 성 요구 사항을 제거 할 수있는 방법을 모색하려고 노력했지만 실제로는 옵션이 아닙니다. 이 응용 프로그램은 기본적으로 매우 많은 양의 데이터에 매우 빠른 임의 액세스가 필요하며 데이터베이스를 통해 하드 디스크에 저장해도 잘리지 않습니다.
  • 적어도 이론 상으로는 JVM이 그 정도까지 확장 될 수 있다고 확신합니다. 나는 눈에 띄는 문제없이 Sun 1.6 JVM에 10GB를 할당하여 정기적으로 코드를 실행합니다.

답변:


6

비정상적인 요구 사항은 때때로 비정상적인 솔루션의 혜택을받습니다. 물론, Sun, Dell 또는 HP에 6 명의 인물을 제공하여 수행 할 수는 있지만 도시에서 유일한 게임은 아닙니다.

단일 박스 솔루션의 경우, 가격이 1.000 미만인 홈 브루 메인 보드에서도 최대 128GB를 얻는 것이 매우 저렴합니다 (32 x 4GB ~ USD 3.000). (메이커를 조롱하지 마십시오. Google에 충분하다면 ...)

256GB는 훨씬 비싸고 (32x8GB ~ USD 18.000) 그 이상입니다 ...

또는 Infiniband (10Gbps) 상호 연결된 저렴한 박스를 대안으로 고려한 적이 있습니까?

그런 식으로 4 노드, 16 개의 프로세서 (64 코어), 512GB 머신을 구축 할 수 있으며 여전히 USD 25.000에서 변경 될 수 있습니다.

또한 애플리케이션 중 하나가 실패 할 경우 3 대의 시스템에서 애플리케이션을 실행할 수 있고 최대 8 개의 노드로 비용이 선형 적으로 조정될 수있는 경우 (풀 노드 4 개만 추가) 유예 완전 성능 저하의 추가 이점을 얻을 수 있습니다. 이 시점에서 당신은 <USD 50.000에 대한 멋진 128 코어, 1TB RAM 짐승을보고 있습니다.

Infiniband 제안을 이국적인 것으로 기각하기 전에 요청한 기계 유형에 적합하지 않습니다. 예를 들어 상위 10 대 중 4 대를 포함하여 상위 500 대 슈퍼 컴퓨터 중 141 대가 이러한 방식으로 구축됩니다 ( http://top500.org/connfam/8 )


Infiniband가 올바른 솔루션인지는 알지 못하지만 (경험이 없습니다), (2011 년) 단일 서버에서 100GB + 램으로 Java를 실행하는 시스템을 이국적인 것으로 부를 것입니다. 이국적인 솔루션을 고려해야 할 때입니다.
마이크 밀러

정말 오해의 소지가있는 -1. 톱 500에서 슈퍼 컴퓨터의 대부분은, 낮은 지연 시간 네트워킹을 제공하는 인피니 밴드를 사용 하지 RDMA를 통해 하나의 일관된 이미지를 제공하기 위해 - 그 사용이 입니다 정말 이국적인. 이를 사용하려면 단일 시스템 이미지 또는 vSMP 제품을 사용해야합니다. 이를 위해 Kerrighed 또는 OpenSSI와 같은 것을 사용할 수 있지만 이러한 오퍼링은 수정 된 커널을 기반으로하며 단일 프로세스 이미지를 노드간에 분할 할 수 없습니다. 매우 비싼 솔루션 인 ScaleMP만이 여러 RDMA 연결 서버에서 실질적인 일관성있는 시스템 이미지를 제공 할 수 있습니다.
jgoldschrafe 2014 년

3

알았어 찾고자하는 RAM 풋 프린트가 있고 최소한 자체 그리드가 필요하지 않은 서버는 찾지 못할 것입니다.

확장 가능한 접근 방식을 취하고 memcached를 사용하십시오. 네트워크를 통해 메모리를 다른 시스템으로 분산시킬 수 있습니다. 데이터는 디스크 드라이브에 닿을 필요가 없으며, 원하는 돈으로 구입할 수있는 초고속 네트워크와 함께 대기 시간은 거의 문제가되지 않습니다.

다음은 java 용 memcached 클라이언트입니다. http://www.whalin.com/memcached/

익숙하지 않은 경우를 대비하여 memcached 소개 : http://www.danga.com/memcached/

이것 좀 봐 엄청난 양의 RAM을 가진 단일 몬스터 머신을 구축하는 것보다 훨씬 비용 효율적입니다. 또한, 이런 종류의 요구 사항이있는 작업을 수행하는 경우 미션 크리티컬 일 수 있으며 단일 실패 지점이 필요하지 않습니다.


좋은 생각. 나는 내 생각보다 그것을 더 좋아한다.
phuzion 2016 년

말도 안 돼요 지난 주 서버 부분에서 시작된 Sandy Bridge는 1U 서버 패키지에서 최대 768GB까지 확장 할 수 있습니다. Westmere 부품을 사용하려는 경우 QPI 링크를 통해 두 개의 IBM x3850 또는 유사한 서버를 함께 연결하고 4000 와트 미만으로 전원을 공급할 수 있습니다. (동일한 랙 공간에있는 2 개의 4U 서버와 동일한 전력 풋 프린트입니다.) 아마도 AMD는이 공간에서도 경쟁력있는 제품을 제공하고있을 것입니다.
jgoldschrafe

4
@jgoldschrafe이 질문은 3 년 전에 요청되었습니다.
Matt Simmons

2

HP DL585 또는 DL785 또는 Sun X4600과 같은 4 또는 8 소켓 Opteron 서버는 128-256GB 범위에서 많은 양의 메모리를 사용할 수 있습니다. 저렴하지는 않지만 6 자리 가격표는 아닙니다. 256GB의 RAM을 갖춘 8 웨이 32 코어 Sun X4600은 웹 사이트에서 약 35,000 달러에 판매되며, 이는이 유형의 시스템이 얻는만큼 큰 규모입니다. 웹 사이트에 표시된 정가보다 다소 저렴한 가격으로 시스템을 구입할 수 있다는 것을 알게 될 것입니다.

4Gb DIMM을 사용할 수는 있지만 가격이 비싸지 않은 경우가 많으므로 이러한 시스템을 최대한 활용하는 것이 훨씬 비쌉니다.

이 유형의 시스템을 사용하려면 64 비트 O / S가 필요합니다. 또한 64 비트 JVM을 확보하고 애플리케이션과 잘 작동하는지 확인하십시오.


54 비트 JVM이 아닌 64 비트 JVM을 의미한다고 생각합니다. : P
tegbains


2

이러한 RAM 크기는 절대로주의하십시오. HP 컴퓨터를 64GB로 확장했지만 (라이저 보드, 냉각 샤프트 등을 추가 한 후에 만 ​​(HP와 많은 대화를 나눈 후) HP는 64GB를 사용할 수 있다고 명시했습니다).
머신이 최대 nGB를 갖도록 지정 되었기 때문에 추가 변경없이 작동한다는 의미는 아닙니다. 우리의 경우 모든 일반 메모리 모듈이 작동하지 않았습니다. 뜨거워 졌기 때문에 매우 구체적인 모듈 만 작동했습니다.


1

RAM 비용은 선형 적으로 큰 규모로 확장되지 않습니다. 15 달러에 1GB DIMM을 구입할 수 있다고해서 1,920 달러에 128GB 서버를 구입할 수있는 것은 아닙니다. 처음에는 128 개의 DIMM 슬롯이있는 마더 보드를 찾을 수 없습니다.

특정 크기 (~ 8 ~ 16GB) 이상에서는 완전 버퍼링 DIMM (FB-DIMM)이 필요한 마더 보드 나타나기 시작하는데 , 이는 표준 데스크탑 메모리보다 GB 당 비용이 훨씬 비쌉니다.

우리는 정기적으로 128GB의 메모리를 가진 머신을 사용하며 최근 몇 년 동안 가격이 크게 떨어졌습니다. 그러나 현재 숫자는 없습니다 ... 또는 JVM이 메모리의 크기로 얼마나 잘 확장되는지에 대한 경험이 없습니다. .


1

실제로 HP 목록에서 128GB를 사용할 수있는 BL680c 블레이드, DL580 / 585는 256GB를, DL785는 512GB를 사용할 수있는 옵션이 많이 있습니다. 하나의 Dell과 마찬가지로 IBM의 일부는 256GB까지 올라갑니다.


0

전통적인 하드웨어에서 64GB의 헤드 룸 문제가 발생하기 시작합니다. 거기에서 확장 할 수 있다면 괜찮을 것입니다.하지만 훨씬 더 비용 효율적인 솔루션은 아키텍처에 의문을 제기하는 것입니다. 나는 당신이하는 일에 대한 지식이 없지만 단지 그것을 버리고 있다고 말합니다.


불행히도 RAM 요구 사항을 해결하는 쉬운 방법은 없습니다. 응용 프로그램이 대량의 데이터에 매우 빠르게 임의 액세스해야하기 때문에 디스크에 데이터를 저장해도 데이터가 잘리지 않습니다 :-(

0

아마존의 EC2 솔루션이 적합할까요? 가장 비용 효율적인 솔루션 일 것입니다.


두려워하지 마십시오-EC2 서버가 지원할 수있는 최대 RAM 양은 마지막으로 확인했을 때 14GB입니다.

0

많은 메모리를 서버에 넣을 수 있다고 가정 해 봅시다 (실수하지 않으면 표준 하드웨어의 Linux는 64GB로 제한되지만 확실하지 않습니다).

대부분의 운영 체제에서 JVM은 부분적으로 연속 메모리가 필요하고 부분적으로 운영 체제 제한으로 인해 약 1.4GB-1.6GB의 힙 공간으로 제한됩니다.

따라서 추가 RAM은 하나의 응용 프로그램을 확장하는 데 도움이되지 않으며 응용 프로그램의 여러 인스턴스 만 실행할 수 있습니다. 그러나 여러 코어가 필요하고 다양한 다른 문제가 발생합니다.

그렇게 많은 RAM이 필요합니까? 메모리에 저장하거나 RAM 드라이브를 사용할 수있는 데이터베이스를 찾을 수는 있지만 많은 양의 메모리를 메모리에 저장할 수있는 JVM을 알지 못합니다.


JVM이 1.6GB의 힙 공간으로 제한되지 않고 Sun의 JVM으로 10GB 이상으로 정기적으로 실행하는 것은 물론 64 비트 시스템에 있어야합니다.

동의하지 않습니다. 참조 : unixville.com/~moazam 그리고 여기에 몇 가지 질문이 있습니다. 64 비트 JVM, 현재 64 비트 Mac에서 지원되지 않는 AFAIK, 64 비트 Linux / Win에 대해 잘 모르겠습니다.

64 비트 JVM을 사용하고 있으며 실제로 Mac에서 하나를 사용하고 있습니다. 애플은 64 비트 맥용 자바 1.6을 꽤 오래 전에 출시했다.

Eclipse가 1.6에서 실행되지 않기 때문에 모르겠습니다 ...하지만 괜찮습니다. 그래도 컴퓨터에 넣을 수있는 최대 RAM은 얼마입니까?

나는 항상 16 기가 바이트 힙 64 비트 jvms를 사용

0

더 많은 시스템 메모리를 얻는 일반적인 방법은 더 많은 시스템을 얻는 것입니다. 메모리가 실제로 병목 현상이라면 메모리 용량이 아니라 프로세서와 데이터가 얼마나 잘 연결되어 있는지입니다. 당신이 그것을 잘하기 위해 많은 것들을 확장해야합니다.

명확히하기 위해, 시스템 메모리에 몇 개의 0을 추가하는 것은 아마 당신이 생각하는 것을하지 않을 것입니다. 이제 전체 데이터 세트가 메모리 또는 약간 더 큰 조각에 적합하므로 캐시 무효화와 같은 다른 병목 현상이 발생합니다.

시스템을 확장하는 적절한 방법은 느립니다. 예를 들어 현재 8 기가의 램이 장착 된 4 코어 시스템에서 실행중인 경우 먼저 앱에서 지옥을 프로파일 링하여 실제로 시간을 보내는 위치를 확인한 다음 최대 12 ~ 16 기가의 램을 부딪 히고 방법을 확인하십시오. 프로파일 링 결과가 변경되었습니다.

실제 문제는 다른 리소스에 비해 일반적으로 사용 가능한 것보다 약 100 배의 시스템 메모리가 필요한 이유입니다. 데이터 액세스 패턴이 예측 가능한 방식으로 디스크 대역폭을 늘리는 것이라면 스트라이프 디스크가 여러 개인 RAID 컨트롤러가이를 달성 할 수 있습니다.

데이터 액세스 패턴이 실제로 무작위이면 더 최적화 된 알고리즘을위한 여지가있을 것입니다.


0

아마도 특별한 서버가 필요할 것입니다.

Unisys에서 ES7000을보십시오. 설명이 약간 오래되었습니다.

최대 512GB의 RAM을 지원할 수 있습니다. Windows 및 Linux Enterprise와 같은 잘 알려진 O / S를 사용하고 있습니다.

표준 구성의 경우 ~ 30K가 소요되지만 Itanium과 모든 종소리와 휘파람을 사용하면 ~ 600K까지 올라갈 수 있습니다.

RAM이 많으면 디스크 공간을 전혀 건드리지 않고도 많은 핫 데이터를 유지할 수 있습니다.


0

분명히 64 비트 운영 체제가 필요하지만 수퍼 컴퓨터 영역에 있지 않습니다. 예를 들어, Dell의 PowerEdge R900 및 R905는 256GB RAM과 함께 제공되며 일반 표준 Intel Xeon / AMD Opteron 프로세서를 사용하고 Linux, Solaris 또는 Windows 2003 및 2008을 실행합니다.

물론, Dell에서 직접 RAM을 구매하는 것은 비용 효율적이지는 않습니다 (32 x 8GB의 경우 ~ 35,000 US $를 원하지만 약 23,000 US $, 더 적은 금액을 이미 얻을 수 있습니다). 40,000 US $ 서버를 구매할 경우 적절한 지원을받을 수 있습니다 (256GB RAM이 저렴할 것으로 예상하지 않았습니까? 128GB도 괜찮다면 ~ 12,000 US $를 절약 할 수 있습니다).

100 + GB Java를 실행하는 것은 일반적으로 내가하는 일이 아닙니다.)


0

완벽한 솔루션 : 데이터베이스. 너무 느리다고 말했지만 호스팅하는 것을 기반으로합니다. 이것으로 충분한 RAID0 어레이에 호스팅하는 것은 어떻습니까.

가젯의 경우 400 달러, Pricewatch는 4GB의 경우 55 달러 (호환성을 확인하지 않음)에 칩을 나열하므로 메모리의 또 다른 440 달러입니다. 32GB는 840 달러입니다. (이 장치는 이론적으로 총 64GB의 8GB 칩을 사용할 수 있지만 아직 칩이 지원되지 않습니다.)

이 중 RAID0 4를 사용하면 일반 상자보다 약간 3000 달러 이상 구매할 수 있습니다. 그중 16 개가 1400 만 달러에 해당하는 최고급 제품입니다.

이것이 사용 가능한지 아닌지의 여부는 데이터의 특성에 달려 있습니다. 이러한 장치는 휘발성이며 CF 카드에 백업 할 수 있지만 몇 시간 안에 백업 배터리를 고갈시킵니다.


0

나는 "많은 저렴한 서버"접근 방식의 열렬한 팬입니다. Ubuntu 9.04에서 제공되는 유칼립투스 플랫폼에서 이런 종류의 프로세스를 실행하고있는 것을 보셨습니까? 8, 16 또는 32GB RAM을 실행하는 여러 서버가있는 자체 전용 기가비트 네트워크의 일부 컴퓨터에서 이러한 종류의 프로그램을 실행하고 선형 방식으로 확장하여 필요할 때 더 저렴한 서버를 추가 할 수 있습니다.


0

귀하의 응용 프로그램 특성에 대한 귀하의 의견을 읽었지만 여전히 대안 솔루션을 고려할 수 있습니다.

FusionIO는 하나의 진정한 대안입니다. 그냥보세요 . 10K $로 여전히 고급 서버보다 훨씬 저렴합니다. 1.0GB / s의 쓰기 대역폭-정말 미친 소리입니다.

다른 옵션은 물론 SSD입니다. 인텔 ® X25-E 익스트림 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

10 개 어레이를 레이드 10 어레이에 넣으면 충분한 성능을 얻을 수 있습니다. 32GB 당 USD 400으로 대체 고급 서버보다 훨씬 저렴합니다.


0

FusionIO 제안과 유사하게 동적 RAM을 SATA 인터페이스에 연결할 수있는 장치를 얻을 수 있습니다. 이와 같은 (제품이나 회사에 대한 경험이 없으며 "Google 쇼핑"검색에서 나온 첫 번째 옵션 일뿐입니다).

이 두 가지를 마운트 된 파일 시스템으로 사용하여 앱의 논리를 사용하여 데이터를 캐시하거나 (배터리로 백업되어 부팅 및 기타 정전에도 살아남 아야 함) 스왑 공간으로 사용하여 커널이 사용 방법을 결정할 수 있도록합니다 ( OS 커널은 일반적으로 모든 스왑 위치가 실제 RAM보다 더 느리고 잠복하다고 가정하면 최적화되지만, 이러한 배열을 최대한 활용하려면 크게 조정해야 할 것입니다.)

FusionIO 옵션은 실제로 큰 무언가가 필요한 경우 비용 대비 가치가 높아질 것입니다. 이러한 RAM 드라이브는 타협보다 낫습니다. 128Gb RAM이 가능한 서버와 전체 64Gb가 채워진 서버 중 몇 대가 가격과 성능 측면에서 256Gb 이상을 직접 지원하는 전문 서버와 얼마나 잘 비교되는지 알아보기 위해 독자를위한 연습으로 남겠습니다!


당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.