SK Hynix onthult DDR5-geheugenmodules van 48 en 96GB voor servers -update

SK hynix kondigt tijdens de Intel Innovation Conference twee varianten van zijn DDR5-rdimm-geheugenmodules aan met capaciteiten van 48 en 96 gigabyte. De geheugensticks zijn bedoeld voor serversystemen en cloudtoepassingen. Er is nog geen releasedatum bekendgemaakt.

De 24Gbit DDR5-geheugenmodules hebben een klokfrequentie van 5600 of 6400MHz en maken gebruik van het registered dual in-line memory module-principe. Op deze manier wordt een schrijf- of leesopdracht 'geregistreerd' of gebufferd voordat deze bij de daadwerkelijke dram aankomt. Dit zorgt ervoor dat rdimm-werkgeheugen stabieler en beter schaalbaar is en wordt om die reden doorgaans voor servers gebruikt.

De capaciteit van de geheugenmodules is opvallend, aangezien het gebruikelijk is dat ramgeheugen bestaat uit individuele modules van doorgaans 8, 16, 32, 64 of eventueel 128GB. Volgens Tom's Hardware zijn opslaghoeveelheden van bijvoorbeeld 48 of 96 gigabyte handig voor serverbeheerders omdat het geheugen zo beter afgestemd kan worden op de benodigde hoeveelheid ram per core van een serverchipset. Daarom zouden ook Micron en Samsung dergelijke configuraties geheugenmodules aan het ontwikkelen zijn.

SK hynix onthult tijdens het evenement ook conventionele DDR5-geheugenmodules met 'binaire' hoeveelheden werkgeheugen; onder meer modules met een geheugencapaciteit van 32, 64, 128 en maximaal 256 gigabyte werden tegelijkertijd gepresenteerd, aldus Serve The Home.

Afbeelding via Server The Home

Update, maandag: In het oorspronkelijke artikel stond onterecht dat SK hynix ook geheugenmodules van onder meer 1, 2 en 4GB onthulde, maar dit is foutief van het bronmedium overgenomen. Er zijn minimaal capaciteiten van 32GB beschikbaar. Het artikel is aangepast. Met dank aan dasiro.

Reacties (15)

[Cornicum]

Kan iemand mij uitleggen wat er bedoeld word met benodigde ram per core?
Is er hier een specifiek getal dat beter is? waarom is dit zo?
Ik neem aan dat 48GB significant goedkoper is dan 64GB? of is te veel slecht voor performance?
Kon dit niet vinden bij het gelinkte Tom's hardware artikel.

[MAX3400]

Hierdoor is het geheugen dus deelbaar door 2, 4, 6, 8, 12...48,..64 wat weer overeenkomt met cores (en uiteindelijk) threads in modernere sockets. Plus, en allicht zijdelingse info; hierdoor hoeven / kunnen hypervisors ook niet specifiek NUMA-nodes gaan timen om "net een paar GB" van de buren te lenen; de snelheid van het socket en de memory-controller blijft hierdoor "aanzienlijk hoger" dan als er memory multi-socket uitgedeeld moet gaan worden.

Kort gezegd; als je bepaalde CPU's "iets meer RAM" wil geven later, hoef je niet 12x 64GB te vervangen voor een module van 12x 128GB maar je zou (nadruk) ook kiezen voor een mix & match van 48GB of 96GB wat mogelijk dus efficienter toegewezen kan worden en er minder RAM "niets" te staat doen op bepaalde momenten.

[ACM]

Je zou inderdaad verwachten dat 48GB goedkoper is dan 64GB; voor 16, 32 en 64GB geldt in mijn ervaring in ieder geval dat het redelijk lineair in prijs stijgt.

Maar het punt is juist dat die serverbeheerders zelf bepalen wat ze nodig vinden. Dus daar is geen algemene uitleg voor te geven.

Verder geldt dat er een optimum is voor het aantal modules per cpu en daarmee voor een server; dat heeft te maken met hoeveel geheugenkanalen die cpu's hebben. Vaak is er wel 2, 3 of 4x het aantal geheugenkanalen aan RAM-slots in een server beschikbaar, maar dan moeten de RAM-modules doorgaans wel op een minder hoge snelheid draaien.

Dus er kunnen scenario's zijn waar "aantal geheugenkanalen * 32GB" te weinig ram geeft, maar met 64GB het te duur wordt. En je ivm die performancedrempel ook liever niet naar "1.5*aantal geheugenkanelen * 32GB" wilt.

Het "mix&match" scenario zoals @MAX3400 dat beschrijft zie ik dan zelf weer niet zo snel gebeuren.

[StCreed]

Voor een database server wil je niet teveel geheugen en ook niet te weinig. Te weinig is slecht want dan krijg je veel page swaps, teveel is niet handig omdat er dan potentieel teveel werk bij 1 core komt te liggen. Dus goed kunnen afstemmen van geheugenmodules op cores en op threads is prettig.

[BadRespawn]

Is er hier een specifiek getal dat beter is?

Juist niet; de benodigde hoeveelheid is afhankelijk van het doel.

"het geheugen zo beter afgestemd kan worden op de benodigde hoeveelheid ram per core van een serverchipset"

[SG]

Ik denk dat dit meer iets is hoe kernel in memory in multi socket numa en numa op cpu nuveau alloceerd per core. Dat bepaalde geheugen blokken voor een core of groep aan cores meest lokal is . Ook dat thread management of schedular niet alleen threads en prosessen aan core verbinden maar ook meest lokal memory.
Op zich houd dit in dat cores aanroepen van ver geheugen bij cache mis verminderd wordt en meer lokale geheugen aanspreekt bij grote data.
Numa op cpu niveau is iets wat met chiplets en tile tech nieuw is multi socket en server clusters is iets wat al heel lang in server branch gangbaar is en server OS en server aplicaties daar ook veel beter mee omgaan .

[supersnathan94]

Een kwart terabyte per stick. Man wat een capaciteiten. Met 8 slots duw je daar dus gewoon ff 2 terabyte in.

[Nitroglycerine]

Dat is ergens wel te begrijpen met de hoge cpu core counts van tegenwoordig. De tijd dat je een 8 core CPU in je virtualisatie tool in achten deelde met ieder 8 GB aan geheugen (dus je had 64 GB in de server nodig) is ver achter ons: 64 en 128 core cpu's moeten ook tot single core servers met een redelijke hoeveelheid geheugen opgedeeld kunnen worden.

[Douweegbertje]

Server(moederborden) hebben ook vaak genoeg een grote hoeveelheid aan memory slots. 16 slots is niet heel raar. Als je dus inderdaad een 64 core cpu hebt, dan heb je met 32gb sticks (16*32) = 512gb ram. Per core is dat dus 8gb.

CPU en memory hebben toch echt wel vaak een bepaalde correlatie. Iets wat bijv. 1 cpu met 20 gb geheugen verbruikt is naar mijn inziens een uitzondering (althans, was). "Iets" moet die data ook in het memory gebruiken dus inherent verbruik je cpu.

Wat ik meer denk, is dat cpu cores op zichzelf veel krachtiger zijn geworden waardoor de potentie van cpu op memory verhouding anders is. Je kunt meer memory per core verbruiken dan dat je vroeger kon. Als je puur kijkt naar de Ghz die server cpu's (vooral de moderne!) hebben maar ook gewoon in pure compute kracht, dan kan ik mij voorstellen dat 8gb per core nu peanuts is. Of beter gezegd, cpu minder snel een bottleneck is op cpu/memory usage

Persoonlijk merken we dit zelf ook met ARM machines en bepaalde data-engineering taken. Die gaan eigenlijk scheef op het aanbod wat bijv. een AWS heeft (i.e. memory schaalt evenredig mee met cpu aantal).

[Xander2]

Persoonlijk merken we dit zelf ook met ARM machines en bepaalde data-engineering taken. Die gaan eigenlijk scheef op het aanbod wat bijv. een AWS heeft (i.e. memory schaalt evenredig mee met cpu aantal).

Minder ARM cores gebruiken?

[supersnathan94]

Nouja dat. En het feit dat je in cloud landschap ook vaak 96vCPU’s af kunt nemen. Dan is een multiple van 96 ook handig voor memory. Nu krijg je die vaak met 384GB ram (4gig per core), maar dat is fysiek natuurlijk iets anders geregeld.

[MSalters]

Nee, dat moet niet. Dat is compleet onhandig, zelfs.

Als je als cloudaanbieder 1vCPU servers wil aanbieden, dan geldt daarvoor de normale economische logica. Hoe maak je die 1 vCPU machines voor de laagste kosten? Een 128 core server met 1TB geheugen is duurder dan 2x64 core servers met 512 GB of 4x32 met 256GB.

Je hebt 128-core servers om 128vCPU machines aan te kunnen bieden. Dat kan namelijk niet anders. Dat zijn dus machines waarbij je een multi-socket moederbord hebt met snelle NUMA links. Die zijn niet gratis, maar die verbindingen tussen CPU's zijn zinloos als elke CPU zelf al 32 virtual machines runt met elk 1 vCPU. Die verbindingen zijn wél nodig als thread #117 besluit om data te zenden aan thread #91.

[Damic]

Hell yeah onze volgende server gaat wat meer geheugen hebben en maar 16c/32t (iets met licenties enzo)

[Reactie gewijzigd door Damic op 3 augustus 2024 13:11]

[dasiro]

er zijn geen 1,2,4,8,16GB modules gepresenteerd, dat was een stukje geschiedenisles, al zou het een goeie 1aprilgrap geweest kunnen zijn: nu 1GB DDR5 6400Mhz

(reeds gemeld op het forum)