Il y a 12 ans -
Temps de lecture 6 minutes
Revue de Presse Xebia
La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Actualité éditeurs / SSII
Indisponibilité d’Amazon EC2
Jeudi dernier, Amazon a connu un gros problème de disponibilité de ses serveurs situés dans certaines régions des Etats-unis, perturbant très fortement des sites connus comme Quora, FoursQuare ou Reddit. Cette annonce a déjà été beaucoup commentée, les sceptiques du modèle de cloud computing y voyant la preuve de la méfiance qu’il faut accorder à ces nouveaux services. Il est évident que ces perturbations laisseront des traces pendant longtemps. Que dire par exemple de l’histoire de ce fournisseur d’accès qui, après avoir beaucoup hésité, a mis 6 mois pour migrer et qui a justement fini la migration la semaine dernière ?
On peut néanmoins affirmer qu’Amazon joue assez bien la transparence comme l’attestent les nombreux blogs sur le sujet ainsi que leur page très bien faite sur les statuts de leurs services dans le monde entier. Par ailleurs un autre site permet de voir le statut actualisé des sites impactés.
De plus, comme le souligne ce blog, les torts sont partagés avec les clients d’Amazon qui n’ont pas toujours tenu compte des avertissements de la compagnie, comme le souligne un des responsables d’EveryBlock:
While the acute problem originated with AWS, EveryBlock is not without blame for this downtime. Frankly, we screwed up. AWS explicitly advises that developers should design a site’s architecture so that it is resilient to occasional failures and outages such as what occurred yesterday, and we did not follow that advice.
Sans surprise ce sont les projets ayant le plus tenu compte des avertissements d’Amazon qui s’en sont le mieux sortis. Netflix en est un bel exemple et les 5 leçons qu’ils ont tirées de leurs précédentes expériences sont à méditer. La 3ème leçon, entre autre, est savoureuse: The best way to avoid failure is to fail constantly. Pour cela ils ont mis en place un ensemble de scripts qu’ils ont nommé Chaos Monkey et qui consiste à tuer des instances au hasard afin d’éprouver leur système en permanence.
Coherence 3.7 – Plus de problèmes de large heap
Coherence, la In Memory Data Grid d’Oracle, était comme beaucoup de ses consoeurs minée par le problème de la taille des JVMs.
Alors que les serveurs d’entrée de gamme embarquent 32 Go de RAM pour un prix dérisoire, nos grilles mémoires nous recommandaient laborieusement des heap de 1.5 Go à cause des problèmes de temps de pause du garbage collector. Coherence a pris le taureau par les cornes et suivi le même chemin que Terracotta Big Memory pour ne citer qu’eux : implémenter un memory manager à l’intérieur de la heap. Schématiquement, Coherence alloue au démarrage de la JVM un gigantesque tableau de _byte_ et gère lui même cet espace de stockage. Coherence annonce que nous pourrons désormais utiliser des JVM de 30 Go au lieu des limitations à 2.5 – 2 Go actuelles. Les simplifications seront très nombreuses (nombre de processus et de fichiers de logs à monitorer, sizing des data source / connections JMS utilisées en « write-behind », etc).
Autre innovation plus avant-gardiste qui ne concernera aujourd’hui que peu d’utilisateurs : le support de disques SSD, principalement pour porter les replicas. Enfin une rencontre avec Cameron Purdy, directeur technique de Coherence, pour un projet pour une grande banque parisienne, nous a appris qu’il travaille au support d’Infiniband pour connecter les noeuds d’une grille. Un Coherence 4 à 100 Gbit/s réels ?
Revenons à des cas d’utilisation de la vraie vie, le support de large heap est une grande simplification de mise en oeuvre (plus visible du côté Ops que du côté Devs) et nous avons encore plein d’attentes :
- Des API plus simples et de plus haut niveau (similaires à « JPA ») pour les équipes informatiques « normales » qui ne sont pas composées que de « geeks passionnés » ; même si ces API seraient plus contraignantes que l’API Map & POF actuelle,
- réplication inter-grille avec API de reconciliation (au hasard Londres, New York ou Tokyo pour les banques :-) ),
- outillage de déploiement avec un modèle de packaging (similaire à nos .war) et un système de gestion centralisé de grille (déploiement, monitoring, etc).
Tous les détails sur InfoQ – Oracle Coherence 3.7’s Elastic Data Offers Transparent Overflow from Memory to Solid State Storage.
Le coin de la technique
Sortie de Hudson 2.0
Une nouvelle version majeure du serveur d’integration continu Hudson vient de sortir. Cette nouvelle version 2.0.0 introduit un changement dans la numérotation, en suivant le schémas majeur.mineur.patch, notamment préconisé par le versioning dans OSGi. Il se démarque désormais de la notation en 1.x ({{x}} étant le numéro de build), toujours utilisée par Jenkins.
Plusieurs nouveautés importantes accompagnent cette nouvelle version avec notamment une modification du système de plugin qui repose maintenant sur le conteneur OSGi Sisu, utilisé dans Nexus et Maven3. Ce framework reposant sur Google Guice, il permet l’utilisation des annotations de la JSR330 comme @Inject permettant l’injection de dépendances ou encore @Singleton assurant l’unicité d’une instance d’un bean. Sisu permet aussi l’injection de services OSGi sans avoir à écrire du code spécifique à OSGi.
Hudson reposant principalement sur des plugins, l’utilisation d’OSGi pour les déployer paraît particulièrement pertinente.
Ce nouveau système de plugin reste rétro-compatible avec les plugins Hudson actuels, mais la migration des plugins vers le nouveau système est cependant encouragé.
Jenkins devrait lui aussi supporter le JSR330 dans un avenir proche, permettant ainsi de supporter les plugins migrés. Certaines parties de l’implémentation proviendront directement des développements d’Hudson.
Outre cette importante nouveauté, cette nouvelle mouture apporte quelques fonctionnalités supplémentaires :
- des boîtes de dialogue modales de confirmation,
- la possibilité de nettoyer le workspace avant chaque build,
- l’amélioration du support de maven,
- la possibilité de publier les plugins Hudson dans un dépôt maven.
Il semble donc que la communauté Hudson soit particulièrement active et qu’une saine concurrence soit installée entre Jenkins et Hudson.
CXF 2.4.0 est dans les bacs
La version 2.4.0 de CXF vient de sortir.
Cette nouvelle version apporte de nouvelles fonctionnalités dont :
- des améliorations au niveau de WS-Security avec le support des tokens SAML2, de meilleures performances et un meilleur support de la partie sécurité du profile WS-I Basic,
- databinding JiBX,
- des améliorations pour la transformation des messages XML pour JAX-RS,
- l’ajout d’une console permettant l’accès aux logs CXF,
- l’amélioration du support OSGi, permettant le déploiement de CXF dans un conteneur OSGi comme Apache Karaf,
- une amélioration du temps de démarrage et de l’empreinte mémoire.
Commentaire
13 réponses pour " Revue de Presse Xebia "
Published by Dominique De Vito , Il y a 12 ans
Ah, tiens, Coherence utilise un large tableau de bytes pour échapper aux pbs du GC ? C’est confirmé ?
Ou comment avec un langage à GC, on ne fait plus de malloc/desalloc, mais on est obligé de réaliser une nouvelle implémentation de GC…
A ma question à Cameron – http://www.infoq.com/news/2011/04/coherence-37 – « How much memory can we get today with 3.7 improvements ? », sa réponse est: « We were testing 3.7 with up to 31GB heaps (using G1) with good results. The object count reduction helps, no doubt. »
Donc, je n’imaginais pas que Coherence instanciait un large tableau de bytes pour échapper aux pbs du GC, mais utilisait plutôt G1 avec (éventuellement) une amélioration du code de Coherence pour maximiser la localité des données.
Cela me semblait logique: dans un stockage clé/valeur, les valeurs sont indépendantes les unes des autres et si G1 divise la mémoire en zones, chaque zone peut être GCisée indépendamment des autres (modulo une certaine localité des données) à condition qu’une partition clé/valeur soit (en règle générale) suffisamment petite pour être incluse au sein d’une seule zone G1.
Idéalement, Coherence pourrait utiliser le stockage in-memory (but) off-heap pour échapper aux contraintes du GC.
Pas de bol, d’après ce que j’ai compris ici ou là – http://www.infoq.com/news/2011/04/coherence-37 – les direct java.nio.ByteBuffer ne sont pas assez performants de ce point de vue (sic).
Donc, pour la v3.7, IMHO Coherence met en avant le stockage off-heap, mais sur disques SSD.
C. Purdy a publié sur son blog que sur son laptop avec 2 nœuds de 1Go chaque, pour la JVM, il gérait 100Go de mémoire par nœud (soit 100Go de données métier en tout s’il a pris le facteur de réplicaion par défaut=1).
Dans la heap Java, il y a, j’imagine, les index, le tout dans 1Go de mémoire pour la JVM et le reste (100Go) est sur le SSD. Le tout est décrit comme allant à peu près à la vitesse de la RAM (« To top it off, Elastic Data runs as fast as on-heap data storage! »)
http://www.jroller.com/cpurdy/entry/elastic_data_terabytes_of_cache
J’en déduis que le code de gestion I/O est mieux écrit que le code de gestion des zones in-memory off-heap (re-sic) ~ direct java.nio.ByteBuffer.
Il semble que Oracle préconise plutôt le stockage SSD pour les très très gds volumes de données.
Published by Dominique De Vito , Il y a 12 ans
Si Coherence utilise bien un large tableau de bytes on-heap, le mieux serait d’avoir en fait ce tableau off-heap, non ?
Cela ferait carrément sortir ce tableau de la juridiction du GC, ce serait ainsi plus clair, et de ce fait, la taille de la heap reflèterait mieux la taille des données sous la juridiction du GC.
Pour le JDK 8, ce serait fortement intéressant d’avoir une bien meilleure implémentation des direct java.nio.ByteBuffer, ce qui permettrait de gérer les données de ces buffers avec la même vitesse/efficacité que les données on-heap.
Une des voies intéressantes pourrait être la suivante:
– autoriser les utilisateurs Java SE à allouer des tableaux de données primitives (byte[], int[], etc.) en dehors de la heap (idem les données des direct java.nio.ByteBuffer)
– les données de ces tableaux off-heap seraient utilisables comme n’importe quelle donnée d’un tableau on-heap: pas de syntaxe particulière définie pour l’utilisation de ces tableaux off-heap ; cette capacité serait facilement supportée par le fait que ce sont des tableaux de données primitives.
Voire, le fin du fin, cela serait de disposer dans Java SE des capacités à gérer la mémoire et le GC de manière fine, façon Java RT.
Soit dit en passant, vues que les applis critiques ont besoin de fonctionnalités qui se rapprochent de plus en plus du Java RT, voire qui l’utilisent tout simplement – exemple du milieu bancaire http://www.infoq.com/presentations/delsart-real-time-java – il me semble de plus en plus naturel que les fonctionnalités de Java RT finissent par influencer/infuser celles de Java SE…
Published by Cyrille Le Clerc , Il y a 12 ans
@Dominique
Vous me faites douter :-)
Gros tableau de bytes « on-heap
L’hypothèse de grand tableau de bytes correspond à Configuring the RAM Journal Resource Manager :
Il s’agit bien de mémoire on-heap puisque la documentation du ramjournal-manager indique pour « <maximum-size> « the JVM max heap is typically specified by the -Xmx argument on the java command line) ».
Il faudrait savoir si le journal correspond à un seul tableau ou à plusieurs tableaux. J’avais compris d’une conversation orale qu’il n’y en avait qu’un ; un heap dump lèverait le doute.
stockage off-heap
Coherence a une longue expérience de stockage off-heap mais d’après ce que j’ai compris, ca posait des problèmes jusqu’à maintenant et c’était ‘délicat’ à utiliser (cela correspond à la réponse que C. Purdy vous a fait sur l’article InfoQ).
Coherence 3.7 requiert-il des disques SSD lorsqu’on utilise des large heap ?
La documentation Configuring a RAM Journal Backing Map pourrait laisser croire que le ram-journal qui est essentiel pour les large heap requiert de fonctionner avec un flash-journal. Je n’avias pas compris cela des discussions que j’avais eu et les réponses de Coherence Purdy sur le forum Coherence ne le laissent pas penser non plus (cf Thread: Coh 3.7 RAM Journal scheme docs seem insufficient).
C’est un point à creuser.
Nouveauté essentielle de Coherence ? SSD ? Large Heap ?
Je vote pour les large heap.
Les larges heap me semblent rendre service sans délais aux équipes qui utilisent Coherence (simplification du monitoring, des déploiements, limitations des connections JDBC, etc). Sur mon projet, ca simplifiera beaucoup de choses !
En revanche, le support des SSD me semble réservé à des cas d’utilisation plus spécifiques. Tout le monde n’a pas besoin de grilles de centaines de Go et les difficultés liées à ces volumétries seront réservées à une élite (initial loading, etc). En plus, cela requiert un investissement supplémentaire en matériel qui passera par le choix des disques par les équipes infrastructure, le débloquage des budgets, l’installation, etc. On n’est plus dans le « quick-win » :-).
Merci de m’avoir suivi dans ce jeux de piste :-)
Cyrille
Published by Michaël Figuière , Il y a 12 ans
@Dominique
Je pense que l’un des intérêts d’avoir les données on-heap plutôt que off-heap est de pouvoir les manipuler via des byte[], int[], char[] ou même tout autre type offert par Java, plutôt que par l’API ByteBuffer, ce qui doit permettre ou simplifier l’implémentation des structures de données complexes nécessaires aux possibilités de traitements et de requêtes offertes par Coherence.
Bien sûr le stockage des données on-heap nécessite actuellement un très fin tuning du GC afin d’éviter toute pause excessive (probablement inacceptable dès lors que l’on choisit un stockage en RAM plutôt que sur disque).
Le temps pourrait améliorer cette situation peu agréable :
* G1 de Sun/Oracle pourrait gagner en stabilité à l’horizon du JDK 7
* Le GC pauseless d’Azul pourrait se démocratiser à l’avenir, il est en tout cas l’objet de tous les regards actuellement
* Oracle semble parfaitement conscient de l’importance de cette limitation technique, Mark Reinhold ayant rappelé lors de l’EclipseCon le mois dernier son souhait de rendre la JVM capable de gérer des heaps de plusieurs Go… pour JDK 9
L’attente sera donc probablement encore longue, mais la complexité du problème à résoudre la justifie sans aucun doute.
Michaël
Published by Cyrille Le Clerc , Il y a 12 ans
Concernant le stockage off-heap en RAM (ie.
ByteBuffer.allocateDirect()), j’ai entendu Kirk Pepperdine expliquer qu’il avait vu de nombreux problèmes de points de synchronisation décidés par les JVM.Pour donner des détails sur Coherence, le stockage off-heap en RAM (cf nio-memory-manager) date d’avant 2006 mais j’ai toujours senti les consultants Oracle réticents à l’idée de l’utiliser sur des gros volumes (plusieurs Go). Ils semblaient tout aussi réticents avec le l’offload disque (nio-file-manager).
L’approche « on-heap » me semble moins expérimentale :-).
Cyrille
Published by Dominique De Vito , Il y a 12 ans
@Michaël Figuière
L’argument ne me semble pas tenir bcp.
Si l’on utilise le mode Cohérence/POF de représentation des données (recommandé pour des raisons de perf par ex), les données sont déjà représentées sous forme de données de « bas-niveau »; de fait, propres à être enregistrées dans la RAM off-heap.
Ainsi, par ex, si l’on veut appeler un EntryProcessor sur un noeud Coherence avec une donnée POF, alors il faut, sur le noeud Coherence appelé, transformer la donnée POF en objet métier pour pouvoir appeler la méthode métier cible, puis, s’il y a enregistrement, re-transformer ensuite l’objet métier final en données POF.
Published by Dominique De Vito , Il y a 12 ans
@Cyrille Le Clerc
Oui, j’ai lu qu’il y avait des pbs de perf avec les java.nio.ByteBuffer.
Ces pbs de synchronisation sont un peu navrant ; après tout, il existe bien des tables de hachage synchronisées et d’autres, non. Il devrait en être de même pour les java.nio.ByteBuffer.
Sinon, je confirme, les consultants Oracle sont réticents à l’idée d’utiliser le stockage off-heap en RAM (cf nio-memory-manager).
Mais avec les SSD, ils vont être moins maintenant réticents avec l’offload disque (nio-file-manager). Les SSS semblent encore plus prometteurs: http://pro.01net.com/editorial/514716/des-disques-sss-cinq-fois-plus-rapides-que-les-ssd/
Published by Dominique De Vito , Il y a 12 ans
@Michaël Figuière
Idéalement, avec l’utilisation du POF, on pourrait copier les bytes reçus d’un client vers un java.nio.ByteBuffer avec un appel à System.arraycopy().
Et la conversion des bytes de l’objet stocké vers l’objet métier (par ex, dans le cadre de l’exécution d’un EntryProcessor) pourrait se faire en branchant directement le PofSerializer de cet objet sur les bytes stockés dans le java.nio.ByteByffer.
Ceci étant, vu l’implémentation actuelle des ByteBuffer, c’est pas demain la veille…
Published by Cyrille Le Clerc , Il y a 12 ans
@Dominique
Disques SSD & SSS : je demanderais déjà à mon middleware Java de gérer correctement les 32 Go de RAM disponibles sur un serveur bi processeurs classique avant de s’attaquer aux technologies avant-gardistes :-).
Pour le cas de Coherence, j’ai au minimum besoin de 3 serveurs pour garantir la haute disponibilité de ma grille.
Avec 30 Go de RAM disponible par machine, si je n’ai que 30 % de mémoire efficace par JVM Coherence ( pour laisser 30 % pour la copie de backup et 30 % de sécurité), j’ai 3 serveurs * 30 Go RAM * 30 % = 30 Go de données dans ma grille. C’est déjà compliqué à gérer en production (initial loading, préserver la consistence avec le SGBD sous-jacent, etc). Je n’ai pas besoin de multiplier par 5 ce volume de données pour me faire de noeuds dans le cerveau :-)
Cyrille
Published by Dominique De Vito , Il y a 12 ans
@Cyrille Le Clerc
La doc Coherence de la v3.7 parle de RAM pour Elastic Data, pas de on-heap ou de off-heap.
Mais j’imagine qu’il s’agit effectivement de on-heap.
Je me demande si l’allocation de larges tableaux de bytes est possible avec un autre algo que G1… Je me demande par ex si G1 a la possibilité de définir ses zones en épousant la limite de ces tableaux…
Par ailleurs, perso, j’imagine l’utilisation de SSD (et donc, de très larges volumes de données) en priorité pour la définition de cache et non pour l’utilisation datagrid, vu le ratio CPU/volume de données moins favorable.
Dans ce cas, l’intérêt est aussi peut être du coté du pricing de Oracle : cela évite de multiplier les VM et donc, le prix de Coherence.
Sinon, rapports aux chiffres exprimés dans votre dernier paragraphe, je vois que l’on a peut être les mêmes sources ;-)
Published by Cyrille Le Clerc , Il y a 12 ans
@Dominique
Gros tableaux de bytes & large heap
J’ai cru comprendre que les garbage collectors classiques sont aussi éligibles. L’enjeux est que le garbage collector ne cherche pas à déplacer le tableau lors de ses Full GC (e.g. pendant la phase de compaction). Mais sur le fond, étant donné la difficulté de gérer des la difficulté de gérer des large heap en Java, je laisserais ce travail exploratoire à un éditeur/projet-open-source de middleware java plutôt que de le traiter en tant qu’équipe d’informatique de gestion.
Comme disait l’adage « chacun son métier et les vaches seront bien gardées » :-).
Cyrille
Published by nicolas de loof , Il y a 12 ans
A propos de la news sur Hudson 2.0 :
Sisu n’est pas un conteneur OSGi mais un adaptateur qui a été développer pour porter le modèle de composants de Plexus sur un autre conteneur d’injection de dépendance, en particulier Guice et donc la JSR 330. Hudson 2.0.0 comme Maven 3 n’est donc pas plus OSGi qu’avant
Par ailleurs, cette migration était déjà engagée. Le changement de schéma de numérotation (pas nécessairement lié à OSGi mais plutôt aux habitudes Maven des développeurs de Sonatype) n’imposait donc pas un changement de version majeure. Il me semble qu’on ai plutôt dans la com’ avec une version majeure qui n’apporte aucun changement majeure mais permet de dire qu’on avance.
Published by Dominique De Vito , Il y a 12 ans
De manière amusante, je suis tombé récemment sur un post relatif au coût du GC
« Delaying Garbage Collection Costs »
http://www.javaspecialists.eu/archive/Issue191.html
Ce billet répond à un post du blog « The Coder’s Breakfast », à propos de comment optimiser un programme donné pour qu’il tourne 10 fois plus rapidement, mais sans changer le code de ce programme.
Je vous laisse découvrir « Delaying Garbage Collection Costs », tout en indiquant ici de manière résumée qu’une « optimisation » consiste à bloquer le GC ; ce qui laisse sous-entendre le cout du GC dans certains cas.
Bon, il faut quand même garder ici à l’esprit qu’il s’agit de micro-benchmarks, mais cela donne une idée, quand même, de l’importance que peut avoir dans certains cas, le coût du GC. Cela n’est pas sans rapport avec l’allocation de larges tableaux dont nous avons discuté plus haut pour atteindre de larges heaps Java.