mardi avr. 13, 2010

ZFS pour base de données Oracle : Best Practices

Translate in English

Le mois dernier, Alain Chéreau, expert Solaris et Oracle du Sun Solution Center, a partagé son retour d'expérience sur l'optimisation des bases Oracle sur ZFS. C'est donc avec un peu de retard, à la veille de la prochaine conférence du GUSES sur DTrace, que je vous livre les points clés de son intervention.

Les quelques bases de tuning de ZFS restent bien entendu d'actualité :

  • taille de la mémoire utilisé par ZFS

  • dévalidation du mécanisme de flush des caches disques sur baie de disques sécurisés

  • taille du record size, de grande importance dans un contexte Oracle, pour éviter de lire plus de données que nécessaire (du fait du mécanisme de Copy on Write), car les performances d'Oracle sont surtout sensibles aux temps de réponse des écritures et aux débits de lecture

    • Ajuster le recordsize= db_block_size = 8k pour index et tables (très important car supprime énormément de lecture)

    • Garder 128k (défaut) pour redo, undo, temporaire et archivelog

    • Ajuster le recordsize des filesystems des bases DW ayant plus des contraintes de lectures que de batch de mise à jour : recordsize = db_block_size = 16k ou 32k

  • une attention sur le prefetch (en fonction du type de charge).

    A cela Alain a ajouté un certain nombre d'éléments d'optimisation très pertinents.

Gestion des écritures synchrones

Oracle ouvre tout ses fichiers en O_DSYNC et demande de ce fait à ZFS d'écrire en mode synchrone. ZFS va donc écrire dans son ZIL (ZFS Intent Log), qui n'est utilisé que pour des écritures de type synchrone. Une fois l'écriture dans le ZIL effectuée, la transaction peut être acquitté côté Oracle. Il est donc important d'aller vite (privilégier la latence). Si on dispose d'une baie disque externe, on mettra le ZIL dans la baie de stockage (ou, sinon sur SSD). 15 secondes de flux d'écriture suffisent comme volume pour le log device de ZFS (ZIL). En outre, si la baie voit que l'on réécrit toujours les mêmes blocks, elle ne va pas l'écrire sur disque et elle va le garder en cache. Un petit ZIL sera donc à préférer à un gros (utilisation d'une slice (64Mo) dans un LUN si les LUN des baies sont trop gros)

Cache Disques, cache ZFS et cache Oracle
Caches à tous les niveaux : c'est la règle générale en transactionnel ! Une fois que le cache hit ratio Oracle est bon, il n'y a plus besoin d'agrandir le cache Oracle et il faut mieux laisser la mémoire restante au cache ZFS car les politiques de cache sont différentes et se complètent.

Ecritures et lectures séquentielles

ZFS écrit en séquentiel (en Copy on Write) : toutes les écritures logiquement aléatoires deviennent séquentielles. Il a donc un comportement optimisé pour des baies de disques (et pas uniquement des disques locaux), et aussi pour les indexes (indexes que l'on va également mettre en générale sur SSD). Par contre, il faut faire attention au comportement de tout ce qui est full scan/range scan (lecture séquentielle) qui du fait du Copy On Write (COW) de ZFS auront été éparpillées. ZFS va quand même regrouper au mieux ses I/Os sur ce type de lecture. Cela aura également un impact sur le comportement des sauvegardes. C'est pourquoi l'utilisation de snapshots peut-être intéressant à ce niveau, ainsi que les fonctions zfs send/receive.

Throughput vs. latency
Il peut être utile lors de grosses écritures séquentielles d'éviter une double écriture (ZIL, puis disques), pour cela il est possible d'indiquer à ZFS en mode « throughput » (mais attention, ensuite il s'applique à toute la machine). Ainsi, si on positionne dans /etc/system zfs_immediate_write_sz à 8000 sur Sparc (sur intel il faut mettre en dessous de 4096 (taille de pagesize et de db_block_size)), toutes les écritures dépassant les 8000 octets seront écrites directement sur le disque (utile pour les processus db writers)

Sur les redolog, la base Oracle aime bien que l'on écrive très vite, il faut donc privilégier le mode latence. Pour cela il faut déclarer un log device (ZIL) séparé sur un ZPOOL des redologs pour ignorer le paramètre « throughput » et garder une bonne latence sur les redologs (vitesse des commits)

Cache ZFS « SSD aware » : adapté pour beaucoup de lectures aléatoires (SGA trop petite, cache primaire (RAM) ZFS trop petit, et beaucoup de lecture aléatoire sur disques). Base avec 'sequential read' très important (>  40%) dans le top 5 des événements Oracle (Statpack ou Awr). Faites attention au warm up du cache secondaire sur SSD... Et c'est bien entendu sans intérêt pour les redologs (écritures).

Mettre les index sur SSD permet également de gagner en bande passante sur les I/O baies qui deviennent dédiées au flux des données.

Optimisation en fonction des profiles de bases
1. Base avec un flux de modification important
utiliser un zpool séparé pour les redologs avec log device séparé (même sur la même LUN en utilisant des slices)

  • une slice pour le ZIL
  • une slice pour le redolog
  • une slice pour les Données (tous les datafiles)
  • Archivelog : n'importe quel disque, même interne

2. Base très active et très importante (volume et activité de l'application)
La séparation des IO sur des disques physiques différents est toujours une optimisation valide : définir des structures disques (zpool/ZFS filesystems) pour séparer redo, tables, index, undo, temp.
Plus le comportement est de type transactionnel (OLTP) plus ce découpage est efficace.
Si le profile est plutôt décisonnel, vous pouvez choisir une approche de type « stripe everything »

Bien entendu, tout cela doit être mis en perspective en fonction de la vie de la baie et est lié à la problématique de mutualisation de bases sur une baie consolidée et des politiques d'évolutions associées.

3. Serveur multi-bases (consolidation)
Utilisez un zpool par usage (redo, datafiles,...) puis ensuite, créez des systèmes de fichiers ZFS par base dans les zpools correspondants.

Gestion des ZPOOL
Garder 20% de place libre dans chaque zpools avec écritures et utilisez l'autoextend des datafiles car la pré-allocation en général utile sur UFS pour jouer sur l'aspect contiguë des données n'a pas d'intérêt avec ZFS (du fait du COW).

ZFS Compression
Sur les Archivelog : allez y !
Sur les datafiles : cela semble une bonne idée... Il faut prévoir 10% à 15% de CPU, mais le gain de place est important. Si vous hésitez à le passer directement sur la production, allez y par contre dans vos environnements de développement et intégration. Et aussi, bénéficiez des capacités de gestion de compression dynamique de ZFS. En effet, à la création de la base, mettez par défaut la compression à « on » : vous allez gagner en place et en temps de création (compression du vide). Ensuite vous pouvez remettre la compression à « off » : ainsi les blocs de données réelles ne seront pas compressés (du fait du mécanisme de COW).

ZFS Clones
Bénéficier du mécanisme de Copy on Write, pour récupérer instantanément un ou des clone(s) de vos bases de données : un moyen simple de fournir de multiple copies modifiables sur même jeu de disques pour développement, recette, intégration...

Checksum Oracle + ZFS : gardez tout ! Plus de sécurité pour un coût CPU faible.

Oracle RAC et ZFS : ils sont incompatibles, car ZFS gère ses méta-data localement.

Les autres points à prendre en compte sur l'optimisation des performances Oracle

  • Mauvais SQL, Contention applicatives
  • Manque de puissance CPU
  • Configuration mémoire (SGA, caches)
  • Contention réseau
  • Débit et capacité en nombre d'IO des disques

Comme le précisait Alain en conclusion de cette session d'optimisation des bases Oracle sur ZFS, « pour aller plus loin, à l'ère des processeurs multi-cores, multi-thread, pensez au parallèlisme !!! » : les statistiques, les sauvegardes, la construction d'index en parallèle sont déjà des bonnes choses en standard à mettre en oeuvre.

J'espère que ces notes vous seront utiles dans la mise en oeuvre de vos bases Oracle sur ZFS.

Merci encore à Alain Chéreau pour son retour d'expérience fouillé sur le sujet. Et n'oubliez pas, demain à Supinfo, la conférence du groupe des utilisateurs Solaris autour de Dtrace, pour vous permettre d'appréhender au mieux son usage et gagner en efficacité sur l'identification et la correction de vos incidents de production.

Translate in English

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

About

Eric Bezille

Search

Archives
« avril 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
    
       
Today