Archive for the ‘Uncategorized’ Category

Modele Mémoire Java vs Physique

Tuesday, January 12th, 2016

La JVM est un modèle complet d’ordinateur, il inclus notamment celui de la mémoire. Mais en pratique cela peut-être très différent du modèle physique et avoir un impact sur le programme. Un modèle mémoire, quant à lui, décrit les conditions dans lesquels une écriture faite par un thread sera visible par un autre thread faisant une lecture. La plupart des développeurs pensent que l’écriture d’une variable quelconque sans aucune synchronisation sera visible de n’importe quel thread faisant une lecture (on appelle se comportement “sequential consistency” ) . Et pourtant, il n’y a pas que la mémoire, le cache etc., qui peuvent poser des problèmes de mémoires, il y a aussi, par exemple, le compilateur. Il est possible par exemple que l’optimisation faite par un compilateur casse une application ! C’est pourquoi il est utile de mieux comprendre le modèle de mémoire proposé par la JVM.
Le modèle mémoire de la JVM.
Le modèle interne de la JVM est relativement simple. Il se décompose en deux grande partie : la pile (heap) et la pile de thread. Chaque thread qui tourne possède sa propre pile, qui contient les appels#160; mais aussi les variables locales de type primitif (ex: int) . Cela implique par exemple que chaque thread à sa propre version d’une variable locale.
La pile (heap) contient elle tous les objets crée par l’application et ce quelque soit le thread qui l’a crée (incluant aussi les objets comme Integer ).
On peut résumer ainsi :
* variable local primitive : stocker dans la pile local
* variable local “objet” : la réference est dans la pile local, l’objet est dans la Heap.
Il est à noté que de ce fait, tous les objets de la Heap peuvent être accéder par n’importe quel thread, à partir du moment ou on a une référence.
Prenons par exemple le code suivant :
public class MyRunnable implements Runnable() {
public void run() {
methodOne();
}
public void methodOne() {
int localVariable1 = 45;
MySharedObject localVariable2 = MySharedObject.sharedInstance;
//... do more with local variables.
methodTwo();
}
public void methodTwo() {
Integer localVariable1 = new Integer(99);
//... do more with local variable.
}
}
public class MySharedObject {

//static variable pointing to instance of MySharedObject
public static final MySharedObject sharedInstance = new MySharedObject();
//member variables pointing to two objects on the heap
public Integer object2 = new Integer(22);
public Integer object4 = new Integer(44);
public long member1 = 12345;
public long member1 = 67890;
}

2 threads déclarent des variables locales, dont l’une pointe ver un objet partagé sur la Heap. les références sont stocké dans chaque pile, mais l’objet est le même sur la Heap. Résultat, les objets 2 et 4 sont accessible par les 2 threads, par contre, les objets 1 et 5 ne le sont pas.

Le modèle physique
Venons en maintenant au modèle physique. De nos jour, un ordinateur est généralement constitué de plusieurs CPU souvent eux même constitué de plusieurs cœurs. Chaque cœur peux faire tourner un thread de façon indépendante. Chaque cœur possède également ses propres registres et de la mémoire cache, de même que le CPU (L1/L2/L3…). Bien évidement, un ordinateur dispose aussi de mémoire RAM commune et accessible à tous. Point important : quand un cœur à besoin d’un élément en RAM, il va le lire dans l’un de ses caches puis dans ses registres. A l’inverse, pour mettre à jour, il va d’abord écrire dans le cache, puis plus tard l’écrire en mémoire. Souvent, ces deux mécanisme ne se font pas unitairement, mais par ce que l’on appel “cache line” ce qui implique la lecture ou l’écriture de plusieurs valeurs en même temps.
cpu-diagram
Rassemblons les deux modèles
Maintenant que nous avons une vision des deux modèles, on peut repérer les différences. il est clair par exemple que le hardware ne fait pas la différence Heap/Stack. On peut aussi comprendre qu’a un instant donné des variables ou de morceau de Heap peuvent se retrouver dans différents endroits : cache, registre, RAM etc …
java-memory-model-5
Et c’est la que les problèmes peuvent arriver !
On peut les classer en deux grandes catégories :
* les problèmes de visibilités
* les “race conditions”
Problème de Visibilité
Imaginons un objet qui se trouve dans la Heap. Initialement stocké dans la RAM. Imaginons qu’un thread souhaite y accéder, comme on l’a vu, l’objet va se retrouver dans le cache d’un CPU. Supposons que l’on fasse des modifications sur cet objet. Tant que le CPU n’aura pas vidé sont cache en RAM, les modifications ne seront pas visible par les autres CPUs qui accèderait à la valeur ! C’est la qu’intervient la notion de volatile qui force la lecture mais aussi l’écriture en RAM de la variable. On appelle aussi cela une “Memory Barrier”, en assembleur se sont des instructions qui force l’ordre d’exécution de certaines actions. Notons que dans certains cas il n’est même pas nécessaire d’avoir plusieurs thread pour être dans ce genre de cas les optimisation du compilateur peuvent avoir ce genre d’effet de bord.
Si on résume : le mot clef volatile indique à la JVM de produire les instructions permettant au processeur de garantir la cohérence de la mémoire RAM.
Attention quand même d’après la JLS :

It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal.

ce qui veux dire que l’on parle d’ordre et pas de temps cpu, et qu’il y a donc des cas ou volatile seul ne suffit pas.
Pour plus de détail vous pouvez vous référer aux $17.4.4 “Synchronization order” et#160; §17.4.5 ‘’”happens-before order” de la JLS
Les Race Conditions
Imaginons cette fois ci que les deux threads font l’opération simultanément.#160; Cette fois, les valeurs sont bonnes, mais le résultat final ne l’est pas. ex: si on a fait 2 additions, on espère avoir 3#160; (1+1+1 !) or on aura 2 (1+1) !
La solution ? la synchronisation ! Un bloc dit synchronisé garantie qu’un seul thread peut entrée dans cette section “critique” à un instant donnée. Au passage, il garantie aussi que toutes les variables seront lues depuis la RAM, et qu’à la sortie du bloc, toutes les variables modifiées seront écrite en RAM et ce qu’elles soit volatile ou non.

Configuration: Modélisation ou Scripting ?

Thursday, October 9th, 2014

 

Quel est la différence entre un langage descriptif et un langage déclaratif ? Prenons un exemple… Si vous cherchez une voiture, vous allez dire, je veux 5 place, un grand coffre, le gps, l’iphone etc… vous n’allez pas demander si la roue est installé par une machine XYZ et un tournevis cruciforme ?

Et bien, c’est cela la différence ! Dans un cas, le langage déclaratif, vous indiquer dans quel état vous souhaitez que le système soit tandis que dans l’autre vous explicitez quels sont les étapes pour y arriver.

Dans le cas de la gestion de configuration, cette différence est important.  En effet, dans un cas vous dite juste, je veux un serveur apache/tomcat, dans l’autre vous dite, il faut récupérer le rpm apache, puis l’installer, puis activer mod_http puis … etc !

Dans le premier cas on modélise l’état que l’on veux avoir, alors que dans le second il faut faire attention a toutes les variantes que l’on pourrait trouver, genre, zut, il y a déjà un apache, je doit vérifier la version etc …

Conclusion

On peut lister ainsi les bénéfices d’une gestion de configuration déclarative :

* c’est répétable : chaque exécution donnera le même résultat quelque soit l’état de départ.

* c’est consistent :encore une fois , quelques soit l’état de départ, l’état d’arrivé sera celui désiré.

* c’est auto-documenté : en général les langages déclaratif sont très simple et facilement compréhensible contrairement à des scripts et en général beaucoup plus concis/compact. Et de fait, devient un atout pour l’auditabilité.

exemple d’outils déclaratif :

* puppet, salt, confsolve, lcfg, bcfg2

exemple d’outils non déclaratif :

* fabric, chef,

That’s Not My Problem - I’m Renting Them

Thursday, October 9th, 2014

 

Cette petite phrase de Adrian Cockroft “That’s not my problem, I’m renting them.”, c’est la réponse un peu imagé qu’il a faite lorsque quelqu’un l’a interrogé sur la fiabilité des SSD !

Un peu imagé, pourquoi ? Parce qu’en fait c’est l’illustration même de l’abstraction qu’offre le cloud. Et c’est bien comme ça qu’il faut voir les choses aujourd’hui. le cloud et plus généralement la virtualisation offre un tel niveau d’abstraction qu’il ne faut plus se préoccuper des ces aspects matériels sauf bien sur si vous en êtes le fournisseur et non l’utilisateur.

vmware et les “large pages”

Tuesday, October 7th, 2014

 

VMWare comme la plupart des OS à une gestion de mémoire qui s’adapte en fonction des usages.

L’un des paramètres sur lequel on peut influer pour affiner ses algorithme s’appelle le “LPageAlwaysTryForNPT”  ou encore l’allocation de pages larges.  Mais Kesako ?

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

En fait tout part du fait que VMware afin d’optimiser la mémoire utilise une technique dite de Transparent Page Sharing (aka TPS) qui permet de partager des pages mémoires identiques afin de libérer de la mémoire. Une sorte de deduplication. A l’origine de ça, les ESX scan régulièrement leurs page de 4Ko afin de trouver de nouveau candidat. D’un autre côté, si le hardware le permet et que l’OS de la VM le demande, ESX préfère utiliser ce que l’on appelle des “larges pages”  soit 2Mo au lieu de 4Ko, mais dans ce cas il va rarement trouver de bon candidat au partage !

A côté de cela, l’ESX comme tout OS va éventuellement swapper la mémoire au besoin. Dans ce contexte, lorsque l’ESX va swapper une page il va devoir la “casser” en petit morceau de 4Ko et va profiter de l’occasion pour tenter de trouver de nouveau candidat au partage. On peut résumer cet effet par “partager avant de swapper”.

Parmi les impacts que cela à, c’est celui de retarder le partage de page.

Le paramètre LPageAlwaysTryForNPT, va permettre de favoriser le page sharing en demandant à l’ESX de n’allouer des large pages que lorsque c’est demandé explicitement par l’OS (par exemple avec MySQL ou Oracle). L’avantage c’est que le reste du temps on aura des pages plus petite (4Ko) et l’action du TPS et donc plus de partage de page.

L’effet va donc dépendre de la workload, si vous avez un système avec de nombreuse “petite” vm, ce sera avantageux car il y aura plus de partage, la consommation mémoire va diminuer et vous pourrez poussez plus loin la consolidation. D’un autre coté si vous avez des grosses VM avec des applications demandant beaucoup de mémoire et donc très probablement des large pages (tel que MysQL ou Oracle ) il y aura plutôt un effet négatif.

Sachez aussi que le paramètre se situe au niveau Host mais aussi au niveau vm (sched.mem.alwaysTryLPageAlloc).

Il faut aussi noter que lors d’un vmotion, l’ESX transfert des pages de 4K, et les regroupe ensuite à nouveau en large page.

docker and xen, complementary not enemies

Wednesday, October 1st, 2014

 

Often seen as competing, containers a la Dockers and hypervisor a la Xen are more complementary than enemies !

By using both technologies we can be more efficient.

let’s see some examples. Dockers mains advantages are a fast boot, simple usage, little (or no) overhead and high density per host but they rely on same kernel/OS which is bad for security and isolation., and well, some “battle” between devs and ops ;-)

ON the other side, Xen let’s you have different OS/kernels,  have more overhead and have a more traditional/mature approach.

Why not use both world ?

Let VM run in a hypervisor with a define set of resources. it offer you (dev) rollback, snapshot and so on easily, considering it as a sandbox.

For the sysadmin, and easy way to handle/extend/replicate resources of VM, even in live with some hypervisor.xen-docker

Ne pas confondre Configuration et Provisionning

Thursday, September 25th, 2014

 

Il y a tellement de buzz ces derniers temps autour des conteneurs comme Docker de la même manière qu’il y a quelques temps autours de la virtualisation, que l’on peut vite oublier cette notion fondamentale.

Il est bon de rappeler qu’il y a deux usages à ces technologies : la scalabilité et le déploiement.

Scalabilité :
Sur la scalabilité, ces 2 technologies sont très bonnes et les deux sont tout à fait à même d’encapsuler un service et de permettre un déploiement rapide de multiple instance avec peu ou pas d’opération post-provisionning.
Et dans ce contexte les deux se valent, et aucune n’est meilleure.

Déploiement :
Coté déploiement, la standardisation des APIs de ces outils permet de ne se focaliser, que, sur le management du container  ou de la machine virtuelle. En effet les APIs permettent de provisionner de manière aussi efficace tant de la VM que du container.
Par contre ce que ces APIs ne permettent pas c’est la Configuration une fois les dit-service provisionnés.

 La Configuration n’est pas du Provisionnement !
Et c’est cette différence qu’il faut bien avoir en tête une fois que l’on veut faire du self-service ! En effet, autant  le provisionnement que ce soit de container ou de vm peut-être une chose aisé autant la configuration des services doit  encore être faite ! Quelque soit le cas d’usage, il y a toujours un minimum d’opération de configuration à faire.
En clair, une fois notre service provisionné, il y a encore du boulot ;-) Par exemple, on ne peut pas imaginer lancer un frontal Apache,  sans définir comment (algo) et/ou sur quel(s) tomcat(s) il devra repartir les requêtes.
Et ce sont bien deux processus distinct ! On peut aussi en dire autant sur la partie monitoring ou surveiller un server ou  un container et bien différent de surveiller un service. On doit bien faire les deux !

On peut par ailleurs se rendre compte que des deux, la configuration à le plus d’impact sur le cycle de vie ! Et c’est de son optimisation que viendra le plus de bénéfice.

quelques différences d’architecture entre Hyperviseur

Wednesday, March 13th, 2013

Dans cet article je vais tenter d’expliquer les différence entre les hyperviseurs les plus courant du marché, en l’occurence VMWare ESX, hyper-v et Xen.

Premier point à savoir, les 3 sont ce que l’on appel des “bare metal” hypervisor, c’est à dire qu’ils n’ont besoin d’aucun OS pour fonctionner (par comparaison le classique VMWare Player lui à besoin de windows ou linux). Malgré tout on verra que ce n’est pas aussi simple.

Autre élément, Xen et Hyper-V sont aussi ce que l’on appel de “paravirtualiseur”, ce qui veut dire qu’ils peuvent faire tourner des invités modifié, utilisant des APIs dédiés dans le but d’amélioré les performances de virtualisation (cela permet par exemple d’utiliser des processeurs qui n’ont pas de jeux d’instructions dédié à la dite virtualisation comme “vt-x” ). Dans le cas de Xen on parle de mode PV ou HVM (Hardware Assisted Virtualization)

la ou les différences apparaisse c’est sur la mise en œuvre de ce fameux “bare-metal”.

Dans le cas d’Hyper-v, on va avoir un noyau qui va crée une première partition (ou invité, dom0 en langage Xen) dans lequel on va retrouver tous les drivers et en l’occurrence ce sera un windows bien sûr. Dans le cas de VMware on va également trouver un noyau (le vmkernel), c’est également lui qui va charger les driver, mais cette fois ils vont se retrouver dans une zone utilisateur dédié et sans privilège. Dans Xen, on va retrouver le comportement d’Hyper-V : l’hyperviseur va crée un premier invité le fameux dom0) dans lequel les drivers seront chargés, par contre à la différence d’hyper-v l’OS n’est pas imposé même si en pratique c’est en majorité du Linux. En pratique, quelle différence cela fait-il ? Et bien se qui peux se passer, c’est que votre partition principale plante pour une raison quelconque. Dans ce cas, vous perdez toutes communication avec le monde extérieur, dans le cas de VMware ce sont des processus séparés, donc tout n’est pas perdu…D’ailleurs pour palier à ce problème, les utilisateurs avancé de Xen crée de plus en plus de invités dédié à chaque driver, on se rapproche ainsi du comportement de VMware avec un avantage supplémentaire dans ce cas : si un invité-driver plante on peut le relancer facilement, voir faire des mise a jours des drivers en live (si, si ça marche ! )

 compare

Dans la serie de différences, due à ce comportement on va trouver aussi un autre point. Ce que l’on peux qualifier d”’”administrative OS”, ce qui représente plus ou moins le moyen que l’on a d’interagir/configurer le noyau de l’hyperviseur. Comme on a pus le constater avec Hyper-v, ce moyen passe par la partition première qui est aussi un OS complet… On voit tout suite ici ce que cela peut impliquer en terme de sécurité d’autant plus que l’on peut y installer n’importe quelle application sans restriction.  Du coté de Xen c’est un peu le même combat, on l’a vus précédement, cependant son coté OS indépendant limite un peu plus ce mauvais point. Du coté de ESX, le point d’entré est une console intégré dans sa propre partition complètement indépendante (au passage pour la petite hisoire, un ESX utilise un boot loader de type redhat, mais dans le processus d’init du kernel RHEL il charge son code en mémoire, puis switch dans celui-ci, crée une première machine virtuel et y place toute la partie bootstrap ainsi que sa console, yep !), il ne reste donc d’accessible que les commandes d’administration (un peu à la manière d’un switch ou d’un busybox)

voila vous en savez un peu plus, pour mieux comprendre ce qui se passe.

Le cold-storage selon Facebook (vous avez dit Exabyte ?)

Thursday, January 24th, 2013

Facebook vient d’annoncer se lancer dans un projet qui peut paraitre « pharaonique » au vus des annonces : construire un Datacenter pour héberger UN EXABYTES de photos (oui vous avez bien lu !!!). Revenons un peu sur cette annonce (faite par Jay Parikh, directeur de l’ingénierie infrastructure chez Facebook) pour comprendre ce que cela implique…

Les chalenges de Facebook

Pour mieux comprendre les chalenges de Facebook, savait vous que Facebook héberge plus de 240 Milliards de photos. Ce qui représente 350 Millions de nouvelles photos par jours mais également 7 Petaoctet de stockage supplémentaire chaque mois !!! Autre point, la plus grosse journée de l’année 2012 pour Facebook c’est Halloween et cela représente entre 1 et 2 milliards de photo sur cette journée. Elément important aussi à noter c’est que 82% du trafic photo n’est généré que par 8% des photos, en reprenant le cas « halloween », en gros après une semaine le milliard de photos ne sera quasiment jamais plus consulté, sic !

le tiered storage

La réponse traditionnelle à ce genre de problématiques est d’utilisé du stockage hiérarchique de style « hot/warm/cold » avec très souvent pour la partie « cold » de la robotique bande. L’objectif étant bien entendu de réduire le cout d’usage tout en trouvant le bon équilibre des différents niveaux.

l’exemple amazon glacier

Depuis quelques mois, Amazon propose une offre positionné sur le segment dit « cold Storage » (en gros le dernier tiers évoqué) avec un tarif très agressif ($0.01$ le Go/mois) et annonce un taux de disponibilité de 99.999999999%. La technologie qui se trouve derrière est peu connues mais parmi les quelques éléments que l’on peut déduire on a comme première info l’usage de matériel ultra standard. Autre point important, pour arriver à de tels coûts il semble obligatoire que les disques et autre serveurs soit éteint la plupart du temps. Cela se confirme en prenant en compte l’usage : on sait que les données versés dedans sont d’abord disponible dans S3, et qu’ensuite un « queue manager » dépile le tout en tenant compte des informations « geolocalisé » des salles machines : nombre de rack, allumé ou éteint, état des disques, consommation électrique , afin d’optimiser les écritures vis-à-vis du coût. Cela se traduit aussi lors des accès en lecture. En effet, Amazon annonce un délai de mise à disposions de 3 à 5 heures, cela corrobore l’idée du système de queue puisque on peut alors penser que notre demande se retrouve dans les files du système et que le gestionnaire choisit le meilleur moment pour la « servir » (à l’occasion d’une écriture par exemple…) et la mettre à disposition pendant 24H00 sur des disques rapides.

les solutions selon Facebook …

Malheureusement, une solution de type « Glacier » ne satisfait pas Facebook, en effet, il ne lui est pas envisageable de dire « vos photos ne sont pas en ligne, merci d’attendre 24h00 pour les visualisées » !!! Du coup, un projet fait son chemin chez eux pour proposer une solution de type « cold storage » mais « rapide », avec comme premier but : le maximum de stockage en minimisant l’énergie !

La première étape de ce système, au plus haut niveau de la pile, est la mise en place d’un logiciel de catégorisation des photos en différents niveau et capable de les déplacer dans les différents containers de stockage définit.

Du coup, on retrouve trois niveaux : un stockage hyperrapide (haystack), un deuxième (le warm) ou les photos sont agrégées et/ou compressées et ou le nombre de réplica diminue (par défaut Facebook stocke un réplica sur chacune de ses quatre régions, bientôt cinq) permettant un gain de place tout en gardant une certains performance. Et dorénavant un troisième niveau (le cold), ou le système va splitter les agrégats précédant en chunk et les placer sur un stockage hyper-optimisé.

Bien sûr, l’élément suivant le plus important pour cela, c’est l’architecture des différents container.

Sub-Zero DC ou les serveurs qui s’allument ou s’éteignent à la demande

Comme on peut le constater à travers l’exemple de Glacier, la grosse difficulté vient du matériel placé dans le Datacenter. A ce titre, Facebook à lancer la construction de deux Datacenter (Prineville et Lulea) dédié à ce projet et d’un troisième (Prineville) plus orienté sauvegarde.

Celui-ci, aussi connus par le nom de code “projet Sub-Zero” vise à avoir une alternative à la sauvegarde sur bande. Facebook gère déjà deux copies de ses données, l’une dite « live » et une autre utilisé uniquement en urgence. L’idée qui fait son chemin est de dire que cette deuxième copie devrait pouvoir être éteinte lorsqu’elle est inutilisée. Facebook travail donc à inventer ce que l’on pourrait qualifier d’un nouveau type de stockage basse consommation avec comme but actuel de réduire celle-ci de 4.5kW par rack à 1.5kW.

“They hope to seriously cut power consumption with Sub-Zero. Right now a rack of Facebook servers burns about 4.5 kilowatts. In the Sub-Zero data center, the goal is to drop this to around 1.5 kWm,”

Le Cold-Storage DC (prineville)

Les deux autres seront clairement dédié au “cold storage”, bâtit sur 5700m^2 avec comme particularité de ne pas avoir de générateur de secours ni UPS et un système de refroidissement standard. Le premier lot sera constitué de 500 racks capables d’accueillir 2Po de données soit un total de 1 Eo (exabyte  ou 1000Po !!) et consommant 1.5MW par salle. De part ces contraintes le logiciel intègre une redondance en gérant lui-même les copies, de même, il est capable d’allouer les différents morceaux sur des racks de différentes chaines électriques.

Mais, Facebook ne va pas s’arrêter là, il envisage déjà d’autres pistes comme celle d’utiliser des mémoires flash déclassées mais aussi de partager une partie de ses technologies dans l’Open Compute Project comme il là déjà fait par le passé.

Source : http://www.datacenterdynamics.com/focus/archive/2012/08/facebook-engineers-dig-deep-overcome-storage-challenges

http://www.opencompute.org/summit-2012/

ImagePrinter new version

Saturday, February 7th, 2009

A new version of my ImagePrinter is availbale : 1.0.511.
please go and check it
* more color profile handling
* better upsizing
* less bugs
* quartz PDF engine for exporting

enfuseEdit : new version

Thursday, November 13th, 2008

A new version of the plugin is available.

The major change is a preview of what will be done !
download it from the enfuseEdit page.