IQ 12.7 et les chargements massifs : influence de la taille des blocs des systèmes ZFS Solaris 10

Introduction

Cet article propose un benchmark pour étudier l’influence de la taille des blocs des systèmes de fichiers ZFS Solaris 10 sur les chargements massifs dans un serveur IQ 12.7. L’objectif est de déterminer la taille optimale du bloc du système de fichiers ZFS par rapport à la taille du bloc définie dans IQ.

L’influence de la taille du bloc IQ et de la taille de page IQ sur les chargements a déjà été réalisée dans un précédent article : "IQ 12.7 et les chargements massifs : influence de la taille des pages et des blocs". Cette étude a montré que le couple par défaut IQ PAGE SIZE/IQ BLOCK SIZE devait être respecté pour obtenir les meilleurs temps de chargement et taux de compression : ces couples par défaut sont 64K/4K, 128K/8K, 256K/16K et 512K/32K. Pour les plateformes 64 bits, les couples optimaux sont 128K/8K (meilleur taux de compression) et 256K/16K (meilleur temps de chargement).

Le contexte des tests de chargement est rigoureusement identique.

Caractéristiques

Caractéristiques du serveur Solaris

Les benchs sont réalisés sur une machine Solaris SPARC 10 (V445), machine qui dispose de 2 CPU à 1,5 GHz. Les disques sont locaux, aucune baie n’est impliquée dans les tests d’écriture.

Caractéristiques du serveur IQ 12.7

Le serveur IQ est une version 12.7 ESD 5 64 bits. Les espaces de stockage IQ Main Store et IQ Temp Store sont respectivement de 10Gb et 2Gb.

Les configurations du serveur IQ dans les jeux de tests restent toujours identiques (caches, etc.) : l’iso-configuration est respectée. Les couples par défaut IQ PAGE SIZE/IQ BLOCK SIZE sont toujours respectés, aussi les seules configurations mises en œuvre sont les suivantes durant les tests :

Caractéristiques de la table à charger

Les chargements massifs sont réalisés sur une table d’environ 71 millions de lignes (INVESTMENT_POSITION) et ces 71 millions de lignes sont réparties sur 8 fichiers correspondant aux 8 trimestres (ou quarter) 2007 et 2008. La commande LOAD TABLE est utilisée pour le chargement massif des trimestres. Voici la répartition du nombre de lignes par trimestre :

La structure de la table INVESTMENT_POSITION est la suivante, elle possède un index unique sur 3 colonnes (index HG unique) :

CREATE TABLE IDW.INVESTMENT_POSITION (
  PORTFOLIO_ID             int           NOT NULL IQ UNIQUE(5000),
  INSTRUMENT_ID            int           NOT NULL IQ UNIQUE(500000),
  [DATE]                   date          NOT NULL,
  TECH_QUANTITY            float         NOT NULL,
  PHYSICAL_QUANTITY        float         NOT NULL,
  STATUS                   char(2)       NOT NULL IQ UNIQUE(50),
  LAST_RECORD_DATE         datetime          NULL,
  VALUATION                float             NULL,
  LAST_VALUATION_DATE      datetime          NULL,
  CREATED_BY               varchar(20)   NOT NULL,
  CREATED_ON               datetime      NOT NULL,
  UPDATED_BY               varchar(20)       NULL,
  UPDATED_ON               datetime          NULL,

  PRIMARY KEY(PORTFOLIO_ID,INSTRUMENT_ID,[DATE])
  
);

L’option de création des indexes FP est activée lors de ces chargements. Aussi les chargements massifs sont réalisés sur une table présentant :

• un index HG unique
• 13 indexes FP

Les trimestres sont toujours montés dans le même ordre et 3 chargements sont réalisés pour une configuration données (IQ PAGE SIZE/BLOCK SIZE) afin d’obtenir une moyenne représentative sur les temps de chargement (phase 1 et 2) et sur les taux de compression.

Les systèmes de fichiers Solaris ZFS

Les systèmes de fichiers ZFS Solaris sont une nouveauté Solaris 10 offrant une souplesse et une productivité accrues dans la gestion des espaces de stockage : parmi les grandes nouveautés de ce type de système de fichiers, la gestion de l’espace est dynamique (diminution, augmentation d’espace…).

Quelques commandes très utiles autour des systèmes de fichiers ZFS et utilisées durant ces benchmarks sont données ici. Les commandes pour la gestion des systèmes ZFS sont très garnies et truffées d’options, seules les commandes qui ont été utiles et nécessaires pour la réalisation de ces tests de performances sont présentées ici.

Pour plus d’informations sur la prise en main de Solaris 10 et ZFS : "Solaris 10 et ZFS, guide pratique. Préparation d’un environnement pour Oracle 10gR2"

Retrouver la taille de bloc d’un système de fichiers ZFS (zfs list)

Pour retrouver la taille de bloc d’un système de fichier ZFS : utiliser la commande zfs list pour la propriété recordsize ou recsize (volblocksize lorsqu’il s’agit d’un volume) :

zfs list -o name,recordsize 

NAME                                RECSIZE
...
DATADEVICES/DBA_T1_ASE/DATADEVICES       2K
...
LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES        4K
...

Modifier la taille de bloc d’un système de fichiers ZFS (zfs set recsize)

La commande zfs set permet de modifier la taille de bloc d’un système de fichier ZFS.

zfs set recsize=<block size> <ZFS_FileSystem> 

• La valeur par défaut est de 128K.
• La taille spécifiée doit être une puissance de 2 supérieure ou égale à 512 octets et inférieure ou égale à 128K.

Cette propriété s’utilise uniquement pour les charges de travail de base de données accédant à des fichiers. La définition de la propriété recsize (ou recordsize) sur une valeur supérieure ou égale à la taille d’enregistrement de la base de données peut améliorer les performances du système de manière significative.

Dans les tests de cet article, la propriété recsize est modifiée avec l’utilisateur root (de 2k à 64k) pour le système de fichiers ZFS LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES, voici des exemples de modification de la taille de bloc de ce système de fichiers :

root% zfs set recsize=2k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES
root% zfs set recsize=4k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES
root% zfs set recsize=8k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES
root% zfs set recsize=16k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES
root% zfs set recsize=32k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES
root% zfs set recsize=64k LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES

Retrouver les disques, les niveaux de RAID et le mirroring d’un système de fichiers ZFS (zpool status)

La commande zpool status permet de retrouver les disques associés aux systèmes de fichiers ZFS, les niveaux de RAID et éventuellement le mirroring mis en place :

zpool status <ZFS_FileSystem> 

Dans l’exemple ci-dessous : la commande zpool status pour le système de fichiers ZFS LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES indique qu’il s’agit du disque c0t3d0. Aucun niveau de RAID et aucun mirroring ne sont mis en œuvre.

root% zpool status LOG-EXPORTS/DBA_T1_ASE/LOGDEVICES

  pool: LOGS-EXPORTS
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
        action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
 config:
        NAME        STATE     READ WRITE CKSUM
        LOGS-EXPORTS  ONLINE       0     0     0
          c0t3d0    ONLINE       0     0     0
errors: No known data errors

Les systèmes de fichiers ZFS ont été introduits avec Solaris 10, toutefois, comme toutes les versions majeures de produits, toutes les nouveautés ZFS n’ont pas été mises à disposition à la première version de Solaris 10, certaines nouveautés ZFS sont introduites progressivement avec des niveaux de patch de Solaris 10 : c’est pourquoi il n’est pas rare de voir dans la résultat de la commande zpool status le message "Upgrade the pool using zpool upgrade".

Dans l’exemple ci-dessous, du mirroring est en place :

root% zpool status SYSTEM
            pool: SYSTEM
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
config:

        NAME          STATE     READ WRITE CKSUM
        SYSTEM        ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c0t0d0s5  ONLINE       0     0     0
            c0t1d0s5  ONLINE       0     0     0

errors: No known data errors

La commande zpool status permet de retrouver les niveaux de RAID, mais cette configuration n’est pas envisagée dans ce document.

iostat -Dnmpx

L’étude est complétée sur les statistiques I/O par les résultats de la commande iostat utilisée avec l’option Dnmpx pour le disque supportant la base IQ. La fréquence appliquée est de 2 secondes.

root% iostat -Dnmpx 2 | grep 'c0t3d0s0'

L’option Dnmpx permet d’obtenir en entête les statistiques r/s (reads per second), w/s (writes per second), kr/s (kilobytes read per second), kw/s (kilobytes written per second).

                    extended device statistics              
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device

   11.0   18.0  896.4  852.4  0.0  0.2    0.0    7.0   0   6 c0t3d0s0

Rappels sur la compression et les chargements (phases 1 & 2)

Compression des données

La documentation est très pauvre au sujet de l’optimisation de la compression des données avec les paramètres IQ PAGE SIZE et BLOCK SIZE, même dans le manuel "Performance & Tuning guide". Tout ce que l’on peut lire est l’information suivante : Sybase IQ compresse les données lors du stockage sur disque; la compression des données réduit l’espace disque consommé et contribue aux performances; le taux de compression est déterminé automatiquement par le moteur IQ et dépend de la taille de page.

Chargements massifs (phases 1 & 2)

Les chargements massifs par la commande LOAD TABLE notifient dans le fichier de message du serveur IQ 2 phases (Insert Pass 1 et Insert Pass 2), exemple :

I. 12/30 16:19:11. 0000000054 [20895]: Insert Pass 1 completed in 109 seconds.
I. 12/30 16:21:36. 0000000054 [20895]: Insert Pass 2 completed in 145 seconds.

• La phase 1 correspond au chargement des données dans les indexes FP.
• La phase 2 correspond au chargement des nouvelles données dans les indexes HG, HNG, LF, etc.

Lorsqu’une table ne contient aucun index autre que les indexes systématiques FP par colonne, la phase 2 est de 0 seconde.

Influence de la taille du bloc ZFS sur la compression des données IQ

Les résultats montrent à nouveau que le meilleur taux de compression de la table INVESTMENT_POSITION est obtenu pour le couple IQ 128K/8K. Dans tous les cas de figure, l’influence de la taille des blocs ZFS est nulle sur le taux de compression.

Quelles conclusions en tirer ?

Influence de la taille du bloc ZFS sur les temps de chargement

Le couple 512K/32K ayant le pire taux de compression, ce dernier est écarté des études.

Étude globale comparative des temps de chargement (phase 1 et phase 2)

La même tendance est toujours observée :

Avant que la taille des blocs ZFS ne soit égale à 8 fois la taille des blocs IQ, le meilleur temps de chargement est obtenu lorsque la taille des blocs ZFS est égale à la taille des blocs IQ.

Lorsque la taille des blocs ZFS est à la fois supérieure à la taille des blocs IQ et inférieure à 8 fois la taille des blocs IQ, les dégradations de performances des chargements varient de 1,6% à 8,72%. La dégradation de performance des chargements est la moins forte pour le couple IQ Page Size/Block Size défini à 128K/8K avec la taille des blocs ZFS définie à 16K et 32K (1,6% de dégradation). La dégradation est la plus forte pour le couple 256K/16K avec des tailles de blocs ZFS définies à 32K et 64K (8,72% de dégradation).

Dès que la taille de bloc ZFS est au moins égale ou supérieure à 8 fois la taille des blocs IQ, des gains de 16 à 4% sont encore observés sur les chargements pour aboutir à des temps de chargement quasi identiques quel que soit le couple IQ Page Size/IQ Block Size (environ 18 minutes). Le couple IQ 128K/8K a une très légère avance sur le temps de chargement avec une taille de bloc ZFS définie à 128K.

Étude des phases 1 et 2

Le seul exemple donné ici est le couple IQ Page Size/IQ Block Size 128K/8K, tous les autres couples montrent rigoureusement la même tendance pour les phases 1 et 2.

Les gains observés précédemment concernent uniquement la phase 2 des chargements (mise à jour des indexes LF, HG, etc.). Les temps de la phase 1 sont très peu influencés par la taille des blocs des systèmes ZFS.

Résultats iostat

Les résultats des commandes iostat confirment les constats précédents. Tous les couples IQ Page Size/IQ Block Size montrent la même tendance en fonction de la taille des blocs ZFS.

La moyenne kr/s (Kilobytes read per second) augmente en continu lorsque la taille du bloc ZFS augmente.

Avant que la taille des blocs ZFS ne soit égale à 8 fois la taille des blocs IQ, la moyenne kw/s (Kilobytes written per second) est la meilleure lorsque la taille des blocs IQ est égale à la taille des blocs ZFS.

Lorsque la taille des blocs ZFS est à la fois supérieure à la taille des blocs IQ et inférieure à 8 fois la taille des blocs IQ, la moyenne kw/s subit une dégradation.

Dès que la taille des blocs ZFS est supérieure ou égale à 8 fois la taille des blocs IQ, la moyenne kw/s augmente de manière très importante et les chargements sont encore optimisés.

Conclusion

Les temps de chargement sont améliorés sur la phase 2 dès que la taille des blocs ZFS est au moins égale ou supérieure à 8 fois la taille des blocs IQ. A partir de cette conclusion, il faut donc envisager la taille minimale suivante des blocs ZFS en fonction du couple IQ Page Size/IQ Block Size :

Pour le dernier couple 512K/32K, il est impossible d’aller au delà de la limite système de 128K pour la taille des blocs ZFS.

En prenant en considération le taux de compression qui est toujours le meilleur pour le couple IQ Page Size /IQ Block Size défini à 128K/8K. La configuration idéale est donc une taille de blocs ZFS définie à 128K avec un couple IQ Page Size /IQ Block Size défini à 128K/8K.