mardi sept. 15, 2009

Soirée GUSES - Groupe des Utilisateurs Solaris (et OpenSolaris)

Translate in English

Hier soir c'était la rentrée pour le GUSES, l'occasion de parler Solaris et OpenSolaris avec des cas d'usages métiers très concrets...
Une soirée où nos amis banquiers étaient assez bien représentés et nous ont fait part de quelques retour d'expériences intéressantes.


1) ZFS et performances

ZFS est très prisé pour sa simplicité et l'ensemble des fonctionnalités qu'il apporte : snapshot, checksum, ....
Reste le point important des performances. A ce titre, je tiens à rappeler l'existence du site ZFS Evil Tuning Guide et notamment quelques paramètres important à positionner :
  • Encadrer l'utilisation de la mémoire système entre ZFS et vos applications (comme iozone, pour les personnes cherchant à effectuer des comparaisons, par example). Dans le cas d'une évaluation récente face à Ext3, sur un système avec 16Go de RAM, le bon paramètrage a été un positionnement du ARC limité à 10 Go (laissant 6 Go pour l'application -IOzone- ).
    Pour limiter le taille mémoire utilisée par ZFS, positionner dans /etc/system : set zfs:zfs_arc_max = 0x280000000 (pour limiter à 10Go)
    En outre, il faut dimensionner la swap de façon adéquate également pour que la réclamation de pages mémoires entre ZFS et les applications se face de façon optimum.

  • Dévalider le flush des caches des disques dans le cas où le système de fichier ZFS se trouve sur une baie de disque avec un cache RAM sécurisé. Si ce paramètre n'est pas positionné, toutes les 5 secondes environs ZFS va forcer la baie à flusher l'ensemble de son cache sur les disques !! Pour plus d'explication et quelques résultats : http://milek.blogspot.com/2008/02/2530-array-and-zfs.html
    Pour dévalider le flush de façon permanente, ajouter dans /etc/system : set zfs:zfs_nocacheflush = 1

  • Utiliser le bon record size au niveau de chacun des systèmes de fichier ZFS
    # zfs set recordsize=8k mypool/myDatafs;zfs set recordsize=128k mypool/myRedologfs
    http://blogs.sun.com/roch/entry/tuning_zfs_recordsize

  • Attention au prefetch de ZFS qui peut avoir un effet de bord additionnel avec le prefetch des baies disques, et conduire à la "pollution" du cache (de la baie). Donc si les I/O ne sont pas séquentielles, il peut être pertinent de dévalider le prefetch de ZFS.
    Pour dévalider le prefetch de ZFS, ajouter dans /etc/system : set zfs:zfs_prefetch_disable = 1

    2) Solaris Temps réel vs. Linux Temps réel
    Un point important recherché avec un système temps réel est son aspect déterministe. C'est ce qu'ont pu observer des utilisateurs de Solaris face à Linux (avec un noyau temps réel) dans ce contexte. Linux a faible charge ayant un traitement plus rapide des requêtes que Solaris, mais étant fortement instable à forte charge (traitement plus long des requêtes que Solaris). Là où Solaris gardait un comportement constant, et donc déterministe...  Pour cela, l'utilisation des techniques de processeurs set (psrset(1M)) et de binding des interrupts (psrset(1M) options -f et -n)  sont des éléments de Solaris intéressant à utiliser.

    3) Les optimisations de Solaris avec Intel Nehalem (Xeon 5500 Series)
    J'ai déjà écrit sur ce sujet, mais depuis, un document assez fouillé sur ces optimisations est disponible à l'adresse suivante :The Solaris Operating System---Optimized for the Intel Xeon Processor 5500 Series

    Il comprend notamment un chapitre pour les développeurs autour des outils d'optimisation et des options de compilation permettant de tirer parti des avancées offertes par le Xeon 5500.

    4) Les fonctions avancées d'OpenSolaris et Solaris pour construire des architectures Cloud
    Mikael Lofstrand, Sun Chief Technologist-Networking vient de publier un document décrivant les architectures associées, étayé au travers de la mise en oeuvre d'une plate-forme Cloud s'appuyant sur ces principes, dont notamment la couche de virtualisation réseau Crossbow et les containers Solaris : The VeriScale Architecture: Towards a Scalable and Elastic Datacenter

    Pour conclure, sachez que les membres du GUSES nous préparent une conférence pour fin octobre, début novembre sur un retour d'expérience client avec la consolidation Solaris sur environnement Oracle utilisant les containers et ZFS.

    Translate in English

mardi févr. 17, 2009

OpenSolaris et Intel Xeon Processor Nehalem

Translate in English

Lorsque nous mettons en place un partenariat, comme dans le cas d'Intel, ce n'est pas pour être un simple revendeur, mais bien pour innover ensemble, et apporter le meilleur des 2 sociétés à  nos clients.
A ce titre, je vous ai déjà parlé de l'ingénierie optimisée de nos systèmes x86/x64, mais notre collaboration va bien au-delà... Solaris (et OpenSolaris) est une des raisons majeures de l'accord de partenariat qui nous lie avec Intel. De part sa stabilité et sa capacité à exploiter des systèmes multiprocesseurs et multi-coeurs, Solaris dispose de fonctions avancées... Fonctions qu'Intel intègre à sa nouvelle architecture multi-coeur, Nehalem  pour :


  • exploiter un grand nombre de Threads, grâce au "Dispatcher" optimisé de Solaris
  • tirer partie des architectures NUMA, avec la fonction "Memory Placement Optimization" (MPO)
  • gérer la consommation d'énergie, au travers du projet TESLA
  • optimiser les performances des machines virtuelles en collaborant dans le projet de Virtualization xVM Server
  • intégrer les nouveaux jeux d'instructions dans les outils Solaris (Studio, ...) pour tirer partie des nouvelles fonctions matérielles du processeur (XML instruction, loop CPC, counters...)

(note: ce n'est pas moi sur la vidéo, mais David Stewart, Software Engineering Manager d'Intel) 

Toutes ces intégrations sont disponibles dans les distributions OpenSolaris2008.11 et  Solaris 10 Update 6.

A cela s'ajoute également l'optimisation des couches logicielles pour les architectures mutli-coeurs.
Sun fournit des logiciels opensource recompilés pour ces architectures, au travers des distributions CoolStack.
Ces logiciels sont disponibles sur architectures x86/x64, mais également SPARC. Car il ne faut pas l'oublier, Sun a toujours une avance importante sur les technologies mutli-coeurs. Nous avons lancé dès 2005 un processeur SPARC CMT (CMT pour Chip Multi-Threading) 8 coeurs, avec 4 threads par coeur, soit 32 threads matériels d'exécution. Ceci a posé un certain nombre d'enjeux au niveau du système d'exploitation. Enjeux qui permettent aujourd'hui à Solaris d'exceller sur ce type d'architectures. Nous sommes aujourd'hui à la 3ième génération de ce processeur (eh oui, une par an, pas mal pour le monde des processeurs), qui supporte 8 coeurs, 8 threads par coeur et des systèmes jusqu'à 4 processeurs (256 threads d'exécutions matériels !).

Maintenant, la question que nous avons souvent : quand utiliser x86/x64 et quand utiliser le processeur SPARC CMT massivement multi-coeurs/multi-threads ?

De façon synthétique, l'architecture x86/x64 est aujourd'hui plus généraliste, et est à privilégier dans les cas où l'application n'est pas mullti-thread, et où la performance d'un thread ainsi que le temps de réponse associé est le facteur important, en bref, clé pour le HPC.

A contrario, le SPARC CMT est vraiment spécialisé pour :

  • les applications fortement multi-threads (Java en fait partie bien sûr, ce qui rend éligible un nombre important d'applications)
  • la prédictibilité du comportement (même sur très fortes charges transactionnelles) : pas de surprise !
  • la consommation électrique optimisée (fréquence moins élevée = moins de dissipation calorifique)
  • le MTBF élevé, de part une intégration importante de fonctions au niveau du processeur (gestionnaire mémoire, I/O, réseau et de cryptographie !)
Un point à ne pas négliger non plus : la configuration et le paramétrage des logiciels dans un environnement multi-coeur change !
Il faut penser différemment et parfois même revoir son paramétrage applicatif à l'inverse des habitudes. Tuning JVM pour mutli-cores : GC ! , pool thread java...!

Donc si vous souhaitez tirer partie au mieux des nouvelles architectures multi-coeurs :
  1. sélectionnez le matériel par rapport à vos besoins : x86/x64 ou SPARC CMT
  2. utilisez le bon OS : Solaris ou OpenSolaris
  3. utilisez la bonne stack logiciel
  4. utilisez les bons paramètres
  5. et obtenez le meilleur meilleur ratio prix/performance/watt/m²

Note : je n'ai pas évoqué ici les systèmes "high-end", SPARC64, car dans une autre classe de serveurs que ceux de type x86/x64 et SPARC CMT. Toutefois, ces systèmes ont un rôle à jouer dans des environnements nécessitant des besoins de croissance applicative verticale (SMP, pour Symetric Multi-Processing), beaucoup d'entrées/sorties et avec un niveau de criticité élevé (car ils disposent notamment de fonctions d'intervention à chaud).

Translate in English

About

Eric Bezille

Search

Archives
« juillet 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today