Azul introduceert 384-core Java-server

Azul Systems heeft de prijzen en specificaties bekend gemaakt van de Java-servers die gebruik maken van de door het bedrijf ontwikkelde Vega-processor. Zoals we eerder schreven is de Vega een processor die is geoptimaliseerd voor het verwerken van de code van de Java VM. Iedere processor is uitgerust met 24 cores die gericht zijn op het uitvoeren van BEA WebLogic en IBM WebSphere Java-applicaties. De low-end machine is uitgerust met 96 cores, 4 processors dus, en 32GB geheugen en zal voor zo'n 89.000 dollar te koop zijn. De high-end versie komt met 384 cores en 256GB geheugen voor 799.000 dollar. De aanpak van Azul is heel anders dan de manier waarop 'normaal' met applicatieservers wordt omgegaan. Vaak worden applicaties op aparte servers gedraaid, zonder dat meerdere applicaties op één systeem in virtual machines draaien.

Omdat de aanpak zo anders is, kan het voor Azul nog moeilijk worden bedrijven te overtuigen van het nut van hun servers. Immers, het vergelijken van de prestaties van deze server met losse servers van IBM of Sun is niet simpel. Volgens Azul komt de kracht van het systeem echt tot zijn recht bij hogere loads; volgens het bedrijf kunnen loads van vijf tot dertig keer zo hoog bij eenzelfde responstijd worden afgehandeld. Een ander probleem is de prijsstelling die BEA en IBM gaan hanteren voor de server. IBM ziet individuele cores als individuele processors en vraagt het volle pond per processor; BEA geeft tot 25 procent korting op dual core-processors. Over 24 cores per processor is nog niet gesproken. Azul stelt dat het met IBM en BEA afspraken heeft gemaakt die 'omzetneutraal' zijn voor de eerder genoemde bedrijven en 'kostenneutraal' voor de klant.

Reacties (12)

[n4m3l355]

de prijzen mogen misschien hoog zijn maar als je denkt hoe klein deze systemen zijn.. de 384 core systeem is maar 11u hoog. in bepaalde omgevingen is ruimte duur en dan is dit wel weer een interessante optie. tevens kan hier ook phyton/sap op gedraaid worden dus naast BEA zijn er nog meer opties

[Jayvd]

Soms is ruimte is inderdaad duur soms maar het lijkt mij dat je beter veel kleinere aparte servers kan hebben. Neem nu de google methode, gewoon heel veel servers gaat er een stuk niets aan de hand. Als deze even weigerd doet niets het meer.

[n4m3l355]

als hier een processor/24 cores... of geheugen in uitvalt lijkt het me sterk dat deze er niet zo uit te trekken zijn. beetje server is toch wel hot-swappable betreffende z'n architectuur. daarnaast google is juist een uitblinker in deze methode en ook alleen mogelijk indien met ongelooflijk veel ruimte heeft. ga jij eens 24 dual systemen in een 11 u rackje stoppen. wordt toch wel een krappe bedoening

[sys64738]

Is t prijsverschil tussen die twee versies niet beetje erg hoog?

Doe denk toch maar 8 van die lichte versies ipv 1 zware. Clustering / loadbalancing kun je daarna zelf wel inplementeren...

[Verwijderd]

Denk dat Azul mooi gebruik kan maken van de grote marketingmachine van Intel en AMD, die nu druk bezig zijn om een soortgelijke overtuiging bij hun klanten teweeg te brengen voor de voordelen van een hogere IPC bij een lagere kloksnelheid en multi-core.

[cyspoz]

Volgens mij is dat een vergelijking die je niet kan maken. Het gaat bij AMD en Intel om krachtige 2 tot 32 weg core systemen. Die presteren dus goed bij bijvoorbeeld 32 threads. Maar wat als er nu 256 threads op zo'n machine draaien. Dan pas komt de kracht van Azuls Java-server naar buiten, omdat al die threads nog steeds op een eigen core kunnen draaien.

Een server van AMD of Intel is geschikt voor een aantal zware processen. Deze Java-server is geschikt voor heel veel gemiddeld zware processen. Denk dat je dan toch een heel andere strategie er op moet nahouden.

[ThunderNet]

Maar wat als er nu 256 threads op zo'n machine draaien

Kijk eens bij je taskmanager hoeveel threads er draaien
Momenteel zijn er op mijn systeem 509 threads.
Dus zo heel veel zijn 256 threads niet...

(open programma's : MSN messenger, 2 x IE, X-Chat, Windows Media Player)

[drm]

Er is een verschil tussen actieve processen en processen die ook daadwerkelijk cpu-time nodig hebben. Je moet je voorstellen dat elk proces aan het OS om een stukje rekentijd kan vragen. Zolang geen enkel proces rekentijd nodig heeft, is de CPU idle. Wanneer er dan 1 thread (proces) om een bepaalde hoeveelheid rekentijd gaat vragen, krijgt het proces in principe nagenoeg de complete capaciteit van de CPU ter beschikking.

Wanneer er echter meerdere threads tegelijk om CPU-tijd gaan vragen, moet je met een enkele core gaan time-slicen. Dus (even kort door de bocht): Thread A mag een paar tijdeenheden instructies doen, dan Thread B, dan Thread C, en dan weer Thread A. Je kunt dan wel nagaan dat, wanneer de Threads in principe van gelijke grootte zijn, dat de threads afzonderlijk drie keer zo langzaam zijn.

Wanneer dat over meerdere cores verdeeld kan worden, krijgen de afzonderlijke threads dus evenveel rekenkracht en heb je dus geen snelheidsverlies.

Wat Cyspoz bedoelt, is dat wanneer je een aantal hele zware threads hebt, 1 afzonderlijke thread normaal gesproken niet over meerdere cores verdeeld kan worden. (Het kan wel, maar dat voert een beetje ver...). Dus zijn single-core processoren met een grote rekenkracht in principe beter voor systemen waar relatief weinig threads op draaien, maar de threads afzonderlijk wel veel rekenkracht vereisen (spellen, bijvoorbeeld).

Daartegenover de multi-cores zijn geschikt voor systemen waar relatief veel threads op draaien maar de threads afzonderlijk niet heel zwaar zijn. Webservers zijn het beste voorbeeld hiervoor; veel requests = veel threads, maar in principe vrij weinig te doen per thread. Ook databaseservers i.c.m. webservers zullen hiervoor wel goed ingezet kunnen worden.

(edit)wat prototype zegt dus

[prototype]

Het grote verschil is -als ik het goed heb begrepen als gevolg van m'n java programmeer hoorcolleges- dat jouw single core processor dit timesliced aanpakt; elke thread heeft een enkele microseconden aan execution time, alvorens de volgende thread weer aan de beurt is. Als je dit maar snel genoeg rouleert, dan wekt het de indruk dat de threads daadwerkelijk paralel aan elkaar verlopen, terwijl dit eigenlijk heel snel sequentieel is.
Bij een multicore systeem is het mogelijk om gewoon daadwerkelijk paralel de threads te laten verlopen, en indien 't aantal threads dat gelijktijdig dient te verlopen hoger is dan het aantal cores, zou dit eventueel timesliced per core nog aangepakt kunnen worden(?).

[cyspoz]

Ja, klopt. Maar volgens mij zijn maar een paar threads actief tegelijkertijd... Maar dat weet ik niet 100%

[Jayvd]

EDIT: Ok