[java] 64 bits in productie?

[flowerp]

Ik vraag me af of er al iemand is die een Java server in een 64 bits omgeving draait.

Voor een specifieke (web) applicatie die met zeer grote datasets kan werken, wil ik binnenkort wat testen gaan draaien.

Na wat rond zoeken op internet vond ik bijvoorbeeld deze link:

http://www.1060.org/blogx...E37DD6705BE96CC2BC27FEA19

Hierin wordt b.v. genoemd dat een 4GB allocatie op een 32bits VM maar liefst 6GB wordt op een 64bits VM, en dat de GC dus zo'n slordige 50% meer geheugen moet heen en weer slepen! De autheur spreeks zelfs van "This is a serious and fundamental problem with 64-bit Java.".

Je zou natuurlijk kunnen zeggen dat een paar andere ontwikkelingen de bovengenoemde nadelen weer opheffen. Geheugen is heel goedkoop momenteel. 4Gb kan je al voor zo'n 80,- krijgen. Jammer dat ik dan 2GB kwijt ben, maar dan stop ik gewoon 16GB totaal in mijn machine; voor het geld hoef ik het niet te laten met de huidige prijzen. Daarnaast is de architectuur van een x86 die in 64 bits mode werkt ook meer geoptimaliseerd. Meer registers, betere addressing modes, etc. Ten slotte is de GC misschien langzamer, maar met de concurrent garbage collector en de velen cores die moderne cpu's hebben is dat wellicht ook wel op te vangen.

Alvorens aan mijn eigen testen te beginnen zou ik graag horen of er mensen zijn die hier concreet ervaring mee hebben, liefst in productie. Is het allemaal zo vreselijk als wordt voorgesteld en zitten we toch voor eeuwig vast aan 32 bits, of valt het in de praktijk allemaal wel mee?

[killingdjef]

Ik kan je geen bron geven dus take it for what its worth, maar het schijnt dat 64bits java inderdaad erg inefficiënt is en er wordt aangeraden om bij 32bits te blijven voorlopig. Ik had hetzelfde gevraagd op een ander forum. Ik zou zelf redeneren dat dit komt omdat 64 bits nog niet mainstream is, zeker niet in serverland.

[.oisyn]

killingdjef schreef op dinsdag 19 februari 2008 @ 00:32:
Ik zou zelf redeneren dat dit komt omdat 64 bits nog niet mainstream is, zeker niet in serverland.

En alle memory management en GC algoritmes moeten voor het 64 bits platform opnieuw worden uitgevonden ofzo? Dat het niet hand-optimized is, soit, maar ik kan me niet voorstellen dat een recompile zo dramatisch slecht zou zijn.

[ Voor 15% gewijzigd door .oisyn op 19-02-2008 00:45 ]

[flowerp]

killingdjef schreef op dinsdag 19 februari 2008 @ 00:32:
Ik kan je geen bron geven dus take it for what its worth, maar het schijnt dat 64bits java inderdaad erg inefficiënt is en er wordt aangeraden om bij 32bits te blijven voorlopig. Ik had hetzelfde gevraagd op een ander forum.

Het punt is een beetje dat ik met wat googlen ook wel op een aantal 'vage' geruchten kom. Een aantal benchmarks die ik tegenkwam blijk dan weer gebaseerd te zijn op antieke JDK die zo ver terug gaan als 1.4 (64 bits bestond toen al voor b.v. Sparc).

Na nog even doorzoeken kwam ik hier op een iets nieuwe benchmark:

http://blogs.sun.com/daga...o_tuning_required_java_se

Hier wordt wel JDK6 gebruikt, zij het de RC1. In deze zie je dat 64bits in 1 geval sneller is, en in 2 gevallen langzamer. In alle gevallen is het niet echt een dag & nacht verschil.

Ik zou zelf redeneren dat dit komt omdat 64 bits nog niet mainstream is, zeker niet in serverland.

Je zou zeggen dat 64 bits op de server juist al veel langer bestaat en dat het voor high performance computing toch wel eens zo langzamerhand mainstream mag gaan worden. Voor x86 worden er al een flink poosje geen 32 bits cpus meer verkocht, en zelfs Debian (het server OS dat altijd erg conservatief is) ondersteund ondertussen officieel AMD64.

[.oisyn]

flowerp schreef op dinsdag 19 februari 2008 @ 00:25:
Na wat rond zoeken op internet vond ik bijvoorbeeld deze link:

http://www.1060.org/blogx...DE37DD6705BE96CC2BC27FEA1

404 not found

Hierin wordt b.v. genoemd dat een 4GB allocatie op een 32bits VM maar liefst 6GB wordt op een 64bits VM, en dat de GC dus zo'n slordige 50% meer geheugen moet heen en weer slepen! De autheur spreeks zelfs van "This is a serious and fundamental problem with 64-bit Java.".

Even afgezien van de vraag hoe je een 4 GB allocatie gaat doen met een 32 bits VM, wat bedoel je precies? Neemt een app die bijv. 4 GB geheugen vreet op een 32 bits machine ineens 6 GB in op een 64 bits machine? Op zich niet heel raar. Als je er vanuit gaat dat ongeveer de helft van de data bestaat uit object handles, en die handles ineens 64 bits worden, dan groeit de hoeveelheid geheugen met factor 1.5. Aan de andere kant kun je je afvragen hoe zinnig 64 bits handles zijn, heb je werkelijk meer dan 4 miljard objecten nodig? Da's nogal veel. Mij lijkt de voornaamste reden om over te stappen op 64 bits de 4 GB memory barrier.

[flowerp]

.oisyn schreef op dinsdag 19 februari 2008 @ 00:52:
[...]
404 not found

Oeps, foutje in de copy-paste van de link. Fixed

Even afgezien van de vraag hoe je een 4 GB allocatie gaat doen met een 32 bits VM, wat bedoel je precies?

Die eerste opmerking is natuurlijk een goede observatie. 4GB kun je helemaal niet alloceren binnen 1 process op een 32 bits machine, dus wat dat betreft heb je eigenlijk sowieso al voordeel als het 1 dataset betreft. In verreweg de meeste gevallen zit Java op 32 bits machines op een praktische limiet van zo'n 1.5GB~1.6GB heap space (er is nog een zooi memory (addressen) nodig voor oa native memory en een aantal interne datastructuren van Java).

Een totaal aan kleine stukjes data kun je wel clusteren over meerdere VM's. Dat is wat ik nu ook doe bij een applicatie die ik ontworpen heb: 3 verschillende VMs alloceren elk zo'n 1.5GB op een 32 bits machine met een big memory kernel. Dat is dus ~4.5GB totaal. Op een 64 bits machine zou dat dus al zo'n 6.75 GB worden begrijp ik.

Aan de andere kant kun je je afvragen hoe zinnig 64 bits handles zijn, heb je werkelijk meer dan 4 miljard objecten nodig? Da's nogal veel.

Ik las ook een stukje over compressed handles/pointers. In de regel is een object natuurlijk veel groter als b.v. 4 bytes, dus hoeven de handles zelf idd niet perse 64 bits te zijn. De JVM kan ook makkelijk weten hoeveel objecten er in gebruik zijn (kun je ook gewoon opvragen aan een JVM), en desnoods on-demand de grote van de handles instellen. Of dat met de JDK6 van b.v. Sun al gebeurd weet ik echter niet.

Mij lijkt de voornaamste reden om over te stappen op 64 bits de 4 GB memory barrier.

De echter barrier voor 32 bits Java is zoals gezegd ~1.5GB. Daar kom je tegenwoordig toch wel snel op. Ik mijn geval gaat het om een simulatie van een proces waarbij zeer veel data is betrokken. Het algoritme is wel te implementeren door eerst segmenten uit te rekenen, maar dat is toch wat rottiger om te maken en te onderhouden.

[Verwijderd]

Ik ken wel projecten die Java 64 bits productie draaien. De link die je aanhaalt is echt sterk overdreven (en praat bovendien over draaien van IDE's en Ant, niet over grote server processen). Er zitten niet alleen nadelen aan 64 bits, maar ook performance voordelen. Your mileage may vary is mijn ervaring, maar ik zou zeker niet verwachten dat de boel ineens explodeert (of ineens vele malen beter presteert).

64 bits is overigens zeker mainstream als server, je moet tegenwoordig je best doen om 32 bits hardware te krijgen. Microsoft vindt sinds Windows Server 2008 32 bits zelfs het "deprecated" platform.

Bij heaps van 8+GB moet je je wel meer zorgen gaan over garbage collection. Ik denk dat je hier wat meer tuning zult moeten doen qua generation groottes en collection strategies om de gc tijden nog enigszins binnen de perken te houden.

[flowerp]

Verwijderd schreef op woensdag 20 februari 2008 @ 23:33:
Er zitten niet alleen nadelen aan 64 bits, maar ook performance voordelen. Your mileage may vary is mijn ervaring, maar ik zou zeker niet verwachten dat de boel ineens explodeert (of ineens vele malen beter presteert).

Interessant. Als je gewoon leest wat de verschillen tussen x86 en x86_64 zijn kun je natuurlijk al beredeneren dat er mogelijk ook performance voordelen zijn. Het feit dat je simpelweg meer registers hebt en betere addressing modes zou voor een specifiek algoritme voordelen op kunnen leveren.

64 bits is overigens zeker mainstream als server, je moet tegenwoordig je best doen om 32 bits hardware te krijgen. Microsoft vindt sinds Windows Server 2008 32 bits zelfs het "deprecated" platform.

Ik vroeg me ook sterk af bij deze thread hoe vaak het nu voorkomt dat mensen 64 bits draaien. Alle hardware is natuurlijk al een flink poosje standaard 64 bits capable, maar de meeste consumenten lijken toch standaard een 32 bits OS te draaien en bij de meeste servers, in ieder geval degene die ik te zien kreeg, installeerde men standaard ook een 32 bits OS.

Natuurlijk is de server wereld groter dan mijn bescheiden blikveld, vandaar dus de vraag hoe vaak het nu voorkomt.

Bij heaps van 8+GB moet je je wel meer zorgen gaan over garbage collection. Ik denk dat je hier wat meer tuning zult moeten doen qua generation groottes en collection strategies om de gc tijden nog enigszins binnen de perken te houden.

Inderdaad. Hoewel ik absoluut nog ermee moet testen, zat ik nu voornamelijk naar de concurrent "low pauze" collector te kijken. Als ik het goed begrijp maakt deze handig gebruik van meerdere cpu's in je systeem en is er niet sprake van een 1 grote 'stop the world' collection. De server die ik wilde gaan inzetten zal waarschijnlijk een 8 core/8GB machine worden of eventueel een 8 core/4GB machine. Om een lange pauze tijd maakte ik me dus zeker wel zorgen.

[Alarmnummer]

Je zou eens kunnen kijken naar cluster software zoals Terracotta. Hiermee is het mogelijk om op een 32 bits platform terabytes aan data in 'virtual heap' te houden. En doordat het ook intelligent kan swappen naar file, hoef je het niet eens fysiek in het geheugen te houden.

http://www.terracotta.org...l+Heap+for+Large+Datasets

En als een applicatie geschikt is (gemaakt) voor een cluster, is het in de toekomst ook een stuk eenvoudiger (lees goedkoper) om te schalen. Met het 'up scalen' zit je toch snel op een dead end.

Project klinkt sexy!

ps:
Ik heb nog bij geen enkele klant een 64 bits Linux installatie gezien en al helemaal geen 64 bits Java installatie.

[ Voor 40% gewijzigd door Alarmnummer op 22-02-2008 16:55 ]

[flowerp]

Alarmnummer schreef op vrijdag 22 februari 2008 @ 16:44:
Je zou eens kunnen kijken naar cluster software zoals Terracotta. Hiermee is het mogelijk om op een 32 bits platform terabytes aan data in 'virtual heap' te houden. En doordat het ook intelligent kan swappen naar file, hoef je het niet eens fysiek in het geheugen te houden.

Dat klinkt zeker wel interessant. Ik werk nu b.v. wel met Jboss cache, daarmee kun je ook je cache clusteren, maar dat werkt meer op het niveau dat een object wat je in de cache hebt gestopt in z'n geheel naar je lokale VM wordt gehaald. Terracotta heb ik al dikwijls zien langskomen, maar nog nooit echt naar gekeken.

Ik vraag me af hoe dat dan gaat als de dataset b.v. 1 grote List is, en mijn code die list iterreerd. Wordt de list dan in z'n geheel naar mijn locale VM gehaald (zal wel niet), of via een soort lazy loading per reference die ik benader?

Even kijk op de link die je gaf:

Terracotta seamlessly determines when to page portions of object graphs in or out

Dat lijkt dus op het laatste geval. Wel interessant als ie ook zo slim is (of ingesteld kan worden) om niet per reference te gaan ophalen uit de remote JVM, maar b.v. 'alle references' 2 levels diep vanaf het huidige Object in 1 keer op te halen.

Ik heb nog bij geen enkele klant een 64 bits Linux installatie gezien en al helemaal geen 64 bits Java installatie.

Toch is dat wel vreemd in zekere zin. Is 64 bits een vergissing geweest? Het is nu al jaren op de x86 markt en op wat niche gebruik na lijkt niemand er aan te willen. Dan had het net zo goed niet naar de x86 kunnen komen. Voor niche gebruik waren er al eerder diverse andere producten.

[Herko_ter_Horst]

Ik kan je gedeeltelijk gerust stellen: wij hebben 64 bits in productie draaien bij een klant, omdat de klant tegen de grenzen van de 32 bits geheugen adresseerbaarheid aanliep (die zoals je al opmerkte in de praktijk voor Java op zo'n 1.5 GB ligt). We hebben in het geheel geen problemen gemerkt tot nog toe.

Nu is het wel zo dat we nog geen enorme heap gebruiken (as in > 8GB) omdat de grens pas net overschreden is. Dus hoe e.e.a. werkelijk schaalt m.b.t. GC e.d. weet ik nog niet (ff kijken of ik nog meer afko's in deze zin kan persen ). We gebruiken tot nog toe een heap van 3 GB, dus theoretisch nog binnen de 32 bits address space. Binnenkort gaan we naar alle waarschijnlijkheid bij een andere klant aan de slag die een écht grote heap nodig gaat hebben (richting 32GB), dus dan weten we meer.

Ik denk dat 64 bits vanzelf komt. En ik denk dat we dat aan Microsoft te danken gaan hebben. Tot en met Windows XP werd de 64 bits versie nog gemarket als iets voor geavanceerde gebruikers en ontwikkelaars, bij Vista zijn beide versies vanaf dag één als gelijkwaardig neergezet. Dit heeft ook tot gevolg dat drivers nu in vrijwel alle gevallen voor zowel 32 als 64 bits goed verkrijgbaar - en kwalitatief gelijkwaardig - zijn. Dat het nu nog niche is komt m.i. doordat de grote massa nog altijd niet meer dan 4 GB nodig heeft. Maar je ziet de verschuiving al wel, tweakers en gamers voorop

[Alarmnummer]

flowerp schreef op vrijdag 22 februari 2008 @ 21:02:
[...]


Dat klinkt zeker wel interessant. Ik werk nu b.v. wel met Jboss cache, daarmee kun je ook je cache clusteren, maar dat werkt meer op het niveau dat een object wat je in de cache hebt gestopt in z'n geheel naar je lokale VM wordt gehaald. Terracotta heb ik al dikwijls zien langskomen, maar nog nooit echt naar gekeken.

Ik vraag me af hoe dat dan gaat als de dataset b.v. 1 grote List is, en mijn code die list iterreerd. Wordt de list dan in z'n geheel naar mijn locale VM gehaald (zal wel niet), of via een soort lazy loading per reference die ik benader?

Misschien zou je de datastructuur iets meer 'cluster'aware gaan maken door te gaan partitioneren. Je zou een lijst van partities (ook weer een lijst) kunnen maken. Ik weet verder vrij weinig van de internals van terracotta af, het staat wel op mijn todo-lijst, maar in de praktijk heb ik er helaas nog geen gebruik van kunnen maken.

Toch is dat wel vreemd in zekere zin. Is 64 bits een vergissing geweest? Het is nu al jaren op de x86 markt en op wat niche gebruik na lijkt niemand er aan te willen. Dan had het net zo goed niet naar de x86 kunnen komen. Voor niche gebruik waren er al eerder diverse andere producten.

Op dit moment zie ik de noodzaak ook nog niet zo 1 2 3. De meeste applicaties hebben relatief weinig geheugen nodig en vaak staan er meerdere eenvoudigere machines ipv een zware machine. En vanuit infrastructuur beheer gezien: waarom extra risico's introduceren? Er zijn nog zo veel bedrijven die werken met volledig gedateerde jvm's.. en dat terwijl ze echt broken zijn (JMM JSR-133):
-finals zijn niet final
-volatile werk niet zoals gewenst (geen piggybacking on synchronization mogelijk).
om maar een paar dingen te noemen

[ Voor 16% gewijzigd door Alarmnummer op 25-02-2008 11:30 ]

[Voutloos]

Alarmnummer schreef op maandag 25 februari 2008 @ 11:26:
En vanuit infrastructuur beheer gezien: waarom extra risico's introduceren? Er zijn nog zo veel bedrijven die werken met volledig gedateerde jvm's..

Waarom niet eens in de zoveel tijd de moeite nemen om alles dat supported software draait te migreren naar een nieuwere stabiele versie?

[Olaf van der Spek]

Voutloos schreef op maandag 25 februari 2008 @ 11:43:
[...]
Waarom niet eens in de zoveel tijd de moeite nemen om alles dat supported software draait te migreren naar een nieuwere stabiele versie?

Nauwelijks tot geen voordelen, wel kans op fouten?

[Olaf van der Spek]

.oisyn schreef op dinsdag 19 februari 2008 @ 00:52:
Aan de andere kant kun je je afvragen hoe zinnig 64 bits handles zijn, heb je werkelijk meer dan 4 miljard objecten nodig?

Handles zijn intern toch gewoon pointers?
Als je alle objecten op 8 bytes aligned zou je nog wat kunnen shiften en 32 gb met 32-bit handles adresseren, maar echt handig lijkt me dat ook niet.

[flowerp]

Olaf van der Spek schreef op woensdag 05 maart 2008 @ 17:48:
[...]
Nauwelijks tot geen voordelen, wel kans op fouten?

De voordelen zijn natuurlijk wel dat je software base zo up to date blijft. Nog afgezien van het feit dat er nieuwere (handige) features in een up to date software base kunnen zitten, is het simpele feit dat het up to date is al een voordeel.

Namelijk, voor oudere software is het na verloop van tijd steeds moeilijker om personeel te vinden die het kan onderhouden. Ook is het na verloop van tijd steeds moeilijker om er hardware voor te vinden waar je het op kan draaien. Extreme voorbeelden zijn b.v. de oude assembly code applicaties op VMS systemen van 30 jaar oud. Daar kun je gewoon geen programmeurs meer voor krijgen.

Hoewel Java erg portable is, zie je het ook bij Java al gebeuren. Leuk dat jouw complete code base nog op Java 1.1 draait omdat je denkt dat er geen voordelen zijn als je naar 1.2 upgrade en alleen maar kans op fouten (iets als Java 6 zal ik niet eens noemen want dat is totaal ondenkbaar als je nog op 1.1 draait en al bang bent voor 1.2).

Probleem is natuurlijk dat er betrekkelijk weinig programmeurs geïnteresseerd zijn om nog met Java 1.1 code te werken. Zelfs de meeste basale classes die je normaal gewend bent om te gebruiken missen dan opeens. Ook zal je een OS moeten blijven draaien dat de 1.1 JVM ondersteund en dat impliceert weer hardware dat dat OS support. Je kunt wel weer het een en ander in virtualisatie gaan draaien natuurlijk, maar echt gelukkig wordt je toch niet van het hele verhaal.

Als je telkens mee upgrade, ook al hoeft het niet perse, blijf je gewoon up to date en zit je niet opeens na 10 jaar tegen een onmogelijke transitie of rewrite aan te kijken.

[.oisyn]

Olaf van der Spek schreef op woensdag 05 maart 2008 @ 17:49:
[...]

Handles zijn intern toch gewoon pointers?

I don't know. Maar dat lijkt mij niet handig, want zodra de VM een object verplaatst in geheugen moet hij referenties aanpassen. Als handles direct een weerspiegeling zijn van dat adres, dan moet ie dus elk object wat aan dat verplaatste object refereert updaten. Anders hoeft hij slechts een element van de handle table (oid) te wijzigen, waarbij een handle effectief een index is in die tabel.

Aan de andere kant geeft dit wel weer een extra indirectie.

[ Voor 5% gewijzigd door .oisyn op 05-03-2008 21:31 ]