Solaris mon amour

précédent 1 2 3 4 5 6 7 8 9 suivant fin

Mardi 20 novembre 2012 2 20 /11 /Nov /2012 22:06

Consommation CPU & Gestion mémoire (1er partie)

Première partie d'une analyse effectuée sur un système Solaris 10 exécutant plusieurs bases de données Oracle. Les symptômes remontés par l'équipe DBA sont les suivants : temps de réponse long sur plusieurs bases.

Un petit vmstat rapide, pour connaitre grossièrement l’utilisation du serveur.

# vmstat 5 100
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m1 m1 s0 s1 in sy cs us sy id
9 0 0 10677368 22372512 680 5482 106 0 0 0 0 25 4 4 4 14735 114426 20380 46 27 27
[…]
23 0 0 9135032 22314120 4792 21638 0 0 0 0 0 1 0 0 0 11118 154028 16758 50 50 0
16 0 0 9137544 22315040 5294 23490 0 0 0 0 0 1 0 0 0 11380 153204 18659 48 52 0
17 0 0 9084960 22258160 2177 10563 0 0 0 0 0 1 0 10 10 9922 137140 14022 43 54 3
24 0 0 9179648 22320080 3362 15628 0 0 0 0 0 1 0 0 0 10750 128918 16896 43 57 0
30 0 0 8850312 22046056 288 2054 0 0 0 0 0 1 0 0 0 10807 99560 14018 31 63 6
126 0 0 8853432 22082880 41 616 0 0 0 0 0 1 0 6 6 5752 31932 6774 10 88 2
661 0 0 8923392 22133776 19 197 0 0 0 0 0 0 0 0 0 2263 5386 1704 3 97 0
465 0 0 8991776 22117088 25 287 0 0 0 0 0 1 0 3 3 2453 8860 2140 4 96 0
46 0 0 8953016 22085792 223 1502 0 0 0 0 0 1 0 0 0 5766 38776 7626 13 86 1
63 0 0 8920736 22079448 109 846 0 0 0 0 0 1 0 0 0 6630 52695 9918 15 83 2
67 0 0 9076624 22190944 1054 7254 0 0 0 0 0 1 0 4 20 5746 97461 7816 33 66 0
53 0 0 8993152 22164344 815 6238 0 0 0 0 0 2 0 176 173 7381 138464 13787 34 66 0
154 0 0 8815312 22116736 37 745 0 0 0 0 0 1 0 0 0 5150 54699 8493 15 85 0
168 0 0 8628120 22079000 22 399 0 0 0 0 0 1 0 0 0 3899 23637 5677 8 92 0
355 0 0 8558232 22016008 23 431 0 0 0 0 0 1 0 4 4 3364 14270 3970 6 94 0
130 0 0 8944384 22119872 949 6035 0 0 0 0 0 1 0 0 0 5608 64746 5932 23 77 0
94 0 0 8696336 22046504 73 782 0 0 0 0 0 1 0 4 4 5918 39593 6905 11 89 0
127 0 0 8570488 21995968 53 560 0 0 0 0 0 1 0 0 0 5745 26933 6982 9 91 0
75 0 0 8915344 22101408 531 4554 0 0 0 0 0 1 0 4 4 6366 81465 9546 23 77 0
26 0 0 8900360 22049976 86 1279 0 0 0 0 0 1 0 0 0 8994 95004 14896 28 71 1
36 0 0 8860368 22037360 184 1635 0 0 0 0 0 1 0 0 0 7535 89424 13136 23 77 0
49 0 0 8820896 22127776 22 1026 0 0 0 0 0 1 0 5 5 10203 71434 12679 22 73 5
427 0 0 8719360 22085440 13 157 0 0 0 0 0 1 0 227 205 3164 8480 2555 4 96 0
487 0 0 8812896 22104528 77 717 0 0 0 0 0 1 0 0 0 2769 9668 2381 5 95 0
42 0 0 9051608 22152568 588 4325 0 0 0 0 0 1 0 0 0 7835 82729 11531 30 69 1
151 0 0 9023256 22246008 188 2021 0 0 0 0 0 1 0 4 4 5405 40646 9076 14 86 0
[..]

Deux remarques vis-à-vis de ce résultat : d’une part la run queue globale est complètement saturée, d’autre part la répartition user/system est de 1 pour 3. Qu’une utilisation system soit supérieur à une utilisation user ne me choque pas forcément, tout dépend des applications, cependant dans mon cas (bases de données Oracle), ce ratio ne me plait pas.

Voyons voir qui utilise tout ce temps kernel.

# dtrace -n 'profile-997hz /arg0/ { @[execname] = count(); }'
dtrace: description 'profile-1001hz ' matched 1 probe
^C
[…]
pgrep 156
nmupm 164
dtrace 166
emdctl 195
check_bnp_proces 225
tnslsnr 638
fsflush 846
sldrm_coll 1182
perl 7639
sched 9911
oracle 17735
emagent 26944

Intéressant, le temps system est utilisé majoritairement par l’agent Grid d’Oracle (emagent). Détaillons d’un peu plus près les fonctions du kernel sollicitées.

# dtrace -n 'profile-997hz /arg0/ { @[func(arg0)] = count(); }'
dtrace: description 'profile-997hz ' matched 1 probe
^C
[…]
unix`bzero 437
unix`_resume_from_idle 446
genunix`mstate_aggr_state 448
genunix`avl_walk 502
FJSV,SPARC64-VI`cpu_smt_pause 549
unix`page_lookup_create 625
unix`mutex_exit 870
unix`utl0 877
FJSV,SPARC64-VI`cpu_halt_cpu 1311
unix`page_exists 1765
unix`mutex_delay_default 2801
FJSV,SPARC64-VI`copyout_more 2934
unix`page_trylock 3246
unix`mutex_enter 5078

Le temps kernel est utilisé principalement à la gestion de lock (mutex). Existe t'il une relation entre ces locks et l’agent Grid ?

# dtrace –n ‘lockstat::mutex_enter: { @[execname] = count(); }’
dtrace: description 'lockstat::mutex_enter: ' matched 3 probes
^C
[…]
dtrace 34218
sh 66256
fsflush 104986
sldrm_hist 186238
nmupm 294968
emdctl 791171
sched 861038
sldrm_coll 1250578
tnslsnr 2617337
perl 3111793
oracle 13825389
emagent 15498584

A priori oui, il existe une relation entre la forte utilisation kernel (mutex) et l'agent Grid (mais pas seulement). Analysons d’un peu plus près la stack de l'agent Grid au moment des locks.

# dtrace –n ‘lockstat::mutex_enter: /execname == “emagent”/ { @[stack()] = count() } \
tick-60s { trunc(@,5); exit(0); }’
dtrace: description 'lockstat::mutex_enter: ' matched 3 probes
[…]
unix`page_trylock+0x38
unix`page_trylock_cons+0xc
unix`page_get_mnode_freelist+0x19c
unix`page_get_replacement_page+0x30c
unix`page_claim_contig_pages+0x178
unix`page_geti_contig_pages+0x618
unix`page_get_contig_pages+0x160
unix`page_get_freelist+0x430
unix`page_alloc_pages+0x110
genunix`anon_map_privatepages+0xa4
genunix`anon_map_getpages+0xad0
genunix`segvn_fault_anonpages+0x32c
genunix`segvn_fault+0x530
genunix`as_fault+0x4c8
unix`pagefault+0xac
unix`trap+0x910
unix`ktl0+0x48
genunix`poll_common+0x5c8
genunix`pollsys+0xf8
unix`syscall_trap32+0xcc
114469

unix`page_trylock+0x38
unix`page_trylock_contig_pages+0x94
unix`page_geti_contig_pages+0x5f4
unix`page_get_contig_pages+0x160
unix`page_get_freelist+0x430
unix`page_alloc_pages+0x110
genunix`anon_map_privatepages+0xa4
genunix`anon_map_getpages+0xad0
genunix`segvn_fault_anonpages+0x32c
genunix`segvn_fault+0x530
genunix`as_fault+0x4c8
unix`pagefault+0xac
unix`trap+0xd50
unix`utl0+0x4c
125499

unix`page_trylock+0x38
unix`page_trylock_cons+0xc
unix`page_get_mnode_freelist+0x19c
unix`page_get_replacement_page+0x30c
unix`page_claim_contig_pages+0x178
unix`page_geti_contig_pages+0x618
unix`page_get_contig_pages+0x160
unix`page_get_freelist+0x430
unix`page_alloc_pages+0x110
genunix`anon_map_privatepages+0xa4
genunix`anon_map_getpages+0xad0
genunix`segvn_fault_anonpages+0x32c
genunix`segvn_fault+0x530
genunix`as_fault+0x4c8
unix`pagefault+0xac
unix`trap+0xd50
unix`utl0+0x4c
17880348

En observant rapidement le résultat, on constaque que les locks proviennent d’allocation de pages mémoire !? Si on regarde un peu plus dans le détail, on constate quelque chose d’intéressant : le système tente d’allouer des pages mémoire de manières contiguës (fonction page_get_contig_pages). Il s’agit « normalement » d’une optimisation du système Solaris (évite la fragmentation mémoire, impact sur les mécanismes de translation d'adresses). Dans notre cas, cela semble pénaliser le fonctionnement du système.

Une petite explication du Support Oracle Solaris sur ce sujet.

The "Large Page Out Of the Box" (LPOOB) feature of the Oracle Solaris 10 memory management, first implemented in Oracle Solaris 10 1/06 (Update 1), can lead to performance problems when the system runs out of large chunks of free contiguous memory. This is because the Oracle Solaris 10 kernel by default will attempt to relocate memory pages to free up space for creating larger blocks of contiguous memory. Known symptoms are high %system CPU time in vmstat, high number of cross calls in mpstat, and Oracle calling mmap(2) to /dev/zero for getting more memory.

Il est possible de changer ce type de fonctionnement par défaut (on alloue des pages sans ce soucier de l’emplacement contiguës de celles-ci) en modifiant le paramètre kernel pg_contig_disable. Petite remarque : ce paramètre influence uniquement la mémoire PGA de la base de données Oracle (pas d'influence sur la mémoire SGA).

Testons rapidement la modification de ce paramètre sur notre système.

# mdb –kw
Loading modules: [ unix genunix specfs dtrace zfs sd mpt px ssd fcp fctl qlc mpt_sas ip hook neti sctp arp usba md cpc random crypto fcip logindmux ptm ufs sppp nfs lofs ipc ]
> pg_contig_disable/X
pg_contig_disable:
pg_contig_disable: 0
> pg_contig_disable/W 1
pg_contig_disable: 0 = 0x1
> pg_contig_disable/X
pg_contig_disable:
pg_contig_disable: 1
> ::exit

# vmstat 5 30
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m1 m1 s0 s1 in sy cs us sy id
10 0 0 10645464 22354816 680 5481 104 0 0 0 0 25 4 4 4 14733 114929 20416 46 27 27
8 0 0 8071552 21199136 865 6976 0 0 0 0 0 1 0 0 0 14630 138815 26507 54 45 1
13 0 0 7960624 21162752 898 6521 0 0 0 0 0 1 0 0 0 12945 115064 23913 46 54 0
6 0 0 8017848 21150384 657 6674 0 0 0 0 0 1 0 0 0 14140 128303 25855 54 45 0
8 0 0 7965472 21129192 704 6301 0 0 0 0 0 1 0 7 7 15013 130409 25934 55 44 1
39 0 0 7908096 21067600 678 6408 0 0 0 0 0 1 0 0 0 14324 113376 26509 46 54 0
11 0 0 7936560 21059424 717 6684 0 0 0 0 0 1 0 0 0 13445 124844 23464 52 47 1
4 0 0 7860976 20987424 880 6478 0 0 0 0 0 1 0 0 0 14499 129461 26395 53 46 0
13 0 0 7881128 21004464 660 6154 0 0 0 0 0 2 0 0 0 15000 124875 25740 50 48 2
5 0 0 7824424 20954160 709 5939 0 0 0 0 0 1 0 0 0 14831 138457 28836 54 45 1
9 0 0 7774880 20924240 1080 8938 0 0 0 0 0 1 0 5 5 13451 126547 24567 50 49 0
[…]

D'une part, la run queue globale est beaucoup moins saturée et, d'autre part, la répartition user/system semble s'être équilibrée. Reste à savoir si la consomation system provient toujours de l'agent Grid ?

# dtrace -n 'profile-997hz /arg0/ { @[execname] = count(); }'
dtrace: description 'profile-997hz ' matched 1 probe
^C
[…]
nmupm 439
init 541
perl 1158
fsflush 1165
collectd 1679
sldrm_coll 2630
emagent 4264
tnslsnr 10857
sched 13906
oracle 105798

La modification du paramètre pg_config_disable semble améliorer le fonctionnement du serveur. L'agent Grid utilise beaucoup moins les ressources system (une bonne chose). Les temps de réponses sont meilleurs mais... Mais voilà : le temps system reste anormalement élevé pour un serveur hébergeant des bases Oracles.

Suite de l'analyse lors d'un prochain article.

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 3 commentaires

Vendredi 16 novembre 2012 5 16 /11 /Nov /2012 20:50

Solaris x86 sur serveur Dell (gamme PowerEdge Rxx0)

Petit article sur la configuration du déport Console Série et des interruptions NMI sur les serveurs Dell (gamme PowerEdge Rxx0).

Configuration d'un déport Console Série

La redirection série s’effectue par défaut sur le COM2 pour les serveurs Dell. Il est donc nécessaire d’effectuer quelques modifications dans Solaris si vous souhaitez l’utiliser correctement.

Il y a deux paramètres importants lors de la configuration : le numéro du port COM et sa vitesse. Ces valeurs doivent correspondre impérativement à la configuration présente dans le BIOS du serveur. Dans mon cas, la redirection série s’effectue sur le COM2 avec une vitesse de 115200 bauds.

Mise à jour de grub

# cat /rpool/boot/grub/menu.lst
#pragma ident "@(#)menu.lst 1.1 05/09/01 SMI"
#
# default menu entry to boot
default 0
[…]

#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris 10 9/10 s10x_u9wos_14a X86
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS,console=ttyb,ttyb-mode="115200,8,n,1,-"
module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris failsafe
findroot (pool_rpool,0,a)
kernel /boot/multiboot -s -B console=ttyb,ttyb-mode="115200,8,n,1,-"
module /boot/amd64/x86.miniroot-safe
#---------------------END BOOTADM--------------------

Mise à jour des « boot environment variables »

# cat /boot/solaris/bootenv.rc
#
# Copyright 2007 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#

#ident "@(#)bootenv.rc 1.33 07/03/03 SMI"
#
# bootenv.rc -- boot "environment variables"
#
setprop ata-dma-enabled '1'
setprop atapi-cd-dma-enabled '0'
setprop ttyb-rts-dtr-off 'false'
setprop ttyb-ignore-cd 'true'
setprop ttya-rts-dtr-off 'false'
setprop ttya-ignore-cd 'true'
setprop ttyb-mode '115200,8,n,1,-'
setprop ttya-mode '9600,8,n,1,-'
setprop lba-access-ok '1'
setprop prealloc-chunk-size '0x2000'
setprop console 'ttyb'

Modification du manifest console-login.xml

L'entrée suivante

devient

Modification du module asy

# cat /kernel/drv/asy.conf
#
# Copyright (c) 1999 by Sun Microsystems, Inc.
# All rights reserved.
#

#pragma ident "@(#)asy.conf 1.12 99/03/18 SMI"

interrupt-priorities=12;
name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3;

Un arrêt + relance du serveur est nécessaire pour valider les modifications. Il vous suffit ensuite de vous connecter au déport console (iDrac) pour valider le bon fonctionnement de la redirection.

Configuration NMI sur serveurs Dell

Sur l’ancienne gamme Dell (tous sauf la gamme gen12), il suffisait d’ajouter le setting ci-dessous dans le fichiers system pour pouvoir interpréter l’interruption NMI envoyée.

# grep nmi /etc/system
set pcplusmp:apic_kmdb_on_nmi=1
set pcplusmp:apic_panic_on_nmi=1

Pour votre culture, le setting « pcplusmp:apic_kmdb_on_nmi » fonctionne uniquement si le kernel est activé en mode debug (instruction kdb à ajouter dans grub).

Etrangement ce setting ne fonctionne plus avec la gamme gen12. Je sais résoudre ce problème sans trop comprendre les raisons subtils du changemennt. En fait le module « pcplusmp » ne semble plus fonctionner (même si vous le charger correctement) pour interpréter les instructions NMI. En recherchant un peu, j’ai decouvert un autre module assez intéressant.

# cd /kernel/mach
# ls -l
total 757
drwxr-xr-x 2 root sys 4 Sep 20 15:04 amd64
-rwxr-xr-x 1 root sys 137528 May 29 10:30 apix
-rwxr-xr-x 1 root sys 120824 May 29 10:30 pcplusmp

Les deux modules « apix » et « pcplusmp » comportent les mêmes variables nmi.

# /usr/ccs/bin/nm ./apix | grep -i nmi
[204] | 432| 4|OBJT |LOCL |0 |4 |acpi_nmi_ccnt
[205] | 436| 4|OBJT |LOCL |0 |4 |acpi_nmi_cp
[207] | 440| 4|OBJT |LOCL |0 |4 |acpi_nmi_scnt
[206] | 444| 4|OBJT |LOCL |0 |4 |acpi_nmi_sp
[590] | 476| 4|OBJT |GLOB |0 |4 |apic_kmdb_on_nmi
[549] | 42121| 176|FUNC |GLOB |0 |1 |apic_nmi_intr
[550] | 1| 1|OBJT |GLOB |0 |COMMON |apic_nmi_lock
[350] | 532| 4|OBJT |GLOB |0 |4 |apic_num_nmis
[349] | 652| 4|OBJT |GLOB |0 |4 |apic_panic_on_nmi
[263] | 0| 0|FUNC |GLOB |0 |UNDEF |psm_add_nmintr
[655] | 0| 0|FUNC |GLOB |0 |UNDEF |tenmicrosec

# /usr/ccs/bin/nm ./pcplusmp | grep -i nmi
[171] | 376| 4|OBJT |LOCL |0 |4 |acpi_nmi_ccnt
[172] | 380| 4|OBJT |LOCL |0 |4 |acpi_nmi_cp
[174] | 384| 4|OBJT |LOCL |0 |4 |acpi_nmi_scnt
[173] | 388| 4|OBJT |LOCL |0 |4 |acpi_nmi_sp
[491] | 420| 4|OBJT |GLOB |0 |4 |apic_kmdb_on_nmi
[453] | 33189| 176|FUNC |GLOB |0 |1 |apic_nmi_intr
[454] | 1| 1|OBJT |GLOB |0 |COMMON |apic_nmi_lock
[300] | 476| 4|OBJT |GLOB |0 |4 |apic_num_nmis
[299] | 596| 4|OBJT |GLOB |0 |4 |apic_panic_on_nmi
[224] | 0| 0|FUNC |GLOB |0 |UNDEF |psm_add_nmintr
[549] | 0| 0|FUNC |GLOB |0 |UNDEF |tenmicrosec

J’ai forcé le chargement du module « apix » (dans le fichier system) pour tester l’interruption NMI.

# grep apix /etc/system
forceload: mach/apix
set apix:apic_panic_on_nmi=1

Soit on modifie la valeur dynamiquement (après avoir loader le module apix) soit on effectue un petit arrêt + relance pour valider la configuration. J'utilise l'outil ipmitool pour générer l'instruction NMI (via le déport console) depuis un autre serveur (natuellement).

# ipmitool -I lanplus -U <user> -H <serveur-sp> power diag

Il ne s'agit pas de grand chose mais la configuration correct d'un déport console (accessible facilement via ssh et non via une interface graphique !!) et la configuration correct du serveur pour pouvoir, en cas de hang (ou pas), prendre facilement un core sont deux éléments obligatoires pour toute production. Je suis encore surpris de rencontrer certaines productions où ces configurations de bases ne sont pas présentes.

Pour aller plus loin :

Gamme PowerEdge Dell
Outil ipmitool
Docs Solaris 10 System Administration Guide: Basic Administration (chapitres 12, 15 et 16)
Docs Solaris 11.1 Booting and Shutting Down Oracle Solaris 11.1 Systems

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : administration
Ecrire un commentaire - Voir les 0 commentaires

Mardi 13 novembre 2012 2 13 /11 /Nov /2012 20:24

Patching a miniroot image (astuce)

Petite astuce pour la mise à jour kernel d'un miniroot Solaris 10. Mais avant de commencer, parlons un peu du contexte. Lors d'une migration p2v d'un serveur Sparc vers une Ldom, j'ai rencontré l'erreur suivante lors de l'extraction de l'archive flar.

{0} ok boot net - install
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-01 64-bit
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.

[…]

No local customization defined

Extracting archive: flar01

Extracted 0.00 MB ( 0% of 11387.00 MB archive)

could not generate hash

ERROR: Could not write to pipe while processing 10.0.0.1:/export/flar/flar01.flar
ERROR: Errors occured during the extraction of flash archive.

The file /tmp/flash_errors contains the list of errors encountered

ERROR: Could not extract Flash archive
ERROR: Flash installation failed

Solaris installation program exited.

# cat /tmp/flash_errors
cannot receive: stream has unsupported feature, feature flags = 0

Le bug ZFS (cannot receive: stream has unsupported feature) est corrigé dans la version kernel 147440-21. Il est donc nécessaire de mettre à jour le miniroot (version kernel actuelle du miniroot 147440-01). Si comme moi, vous suivez la procédure indiquée dans la documentation Oracle, l'installation du patch kernel ne fonctionne pas :

# mkdir /JUMPSTART/miniroot /JUMPSTART/miniroot.patch
# cd /export/install/S10_u0811/Solaris_10/Tools
# ./setup_install_server /JUMPSTART/miniroot
Verifying target directory...
Calculating the required disk space for the Solaris_10 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Copying /boot netboot hierarchy...
Install Server setup complete

# /boot/solaris/bin/root_archive unpackmedia /JUMPSTART/miniroot /JUMPSTART/miniroot.patch
# cd /JUMPSTART/miniroot.patch/sbin
# cp rc2 rc2.orig
# cp sulogin sulogin.orig

# patchadd -C /JUMPSTART/miniroot.patch /var/tmp/147440-23

Checking installed patches...
Executing prepatch script...
df: (/JUMPSTART/miniroot.patch/var/tmp/patchadd-3259121710) not a block device, directory or mounted resource
Insufficient space in /JUMPSTART/miniroot.patch/var/tmp/patchadd-3259121710 to save old files.
Space required in kilobytes: 206535
Space available in kilobytes: 0

Patchadd is terminating.
umount: /JUMPSTART/miniroot.patch/tmp/root/var busy
umount: /JUMPSTART/miniroot.patch/tmp busy
umount: /JUMPSTART/miniroot.patch/mnt busy

Le patch n’a pas été installé (problème dans le script de prepatch). Un cas de figure non validé par l’engineering Oracle !? Etonnant !?

# umount: /JUMPSTART/miniroot.patch/tmp/root/var
# umount: /JUMPSTART/miniroot.patch/tmp
# umount: /JUMPSTART/miniroot.patch/mnt

# mount -F lofs /JUMPSTART/miniroot.patch/var/tmp /JUMPSTART/miniroot.patch/var/tmp

Pour contourner ce petit problème j’ai trouvé une petite astuce banale mais qui fonctionne :

# patchadd -C /JUMPSTART/miniroot.patch /var/tmp/147440-23

Checking installed patches...
Executing prepatch script...
Installing patch packages...

Patch 147440-23 has been successfully installed.
See /JUMPSTART/miniroot.patch/var/sadm/patch/147440-23/log for details
Executing postpatch script...

Patch packages installed:
SUNWcakr
SUNWcakr.3
SUNWcakr.2
SUNWcar.2
SUNWckr
SUNWcsl
SUNWcslr
SUNWcsr
SUNWcsu
[…]

C’est légèrement mieux. Non ? Vérifions sommairement la présence du patch dans le miniroot :

# cd /JUMPSTART/miniroot.patch/var/sadm/patch
# ls
124337-01 147440-23

Encore quelques modifications nécessaires pour finaliser le miniroot :

# export SVCCFG_REPOSITORY=/JUMPSTART/miniroot.patch/etc/svc/repository.db
# svccfg -s system/manifest-import setprop start/exec = :true
# svccfg -s system/filesystem/usr setprop start/exec = :true
# svccfg -s system/identity:node setprop start/exec = :true
# svccfg -s system/device/local setprop start/exec = :true
# svccfg -s network/loopback:default setprop start/exec = :true
# svccfg -s network/physical:default setprop start/exec = :true
# svccfg -s milestone/multi-user setprop start/exec = :true

# cd /JUMPSTART/miniroot.patch/sbin
# mv rc2.orig rc2
# mv sulogin.orig sulogin

# /boot/solaris/bin/root_archive packmedia /JUMPSTART/miniroot /JUMPSTART/miniroot.patch

Voilà le miniroot est à jours, reste à savoir si celui-ci est fonctionnel.

{0} ok boot net -s
Boot device: /virtual-devices@100/channel-devices@200/network@0 File and args: -s
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-23 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.
Booting to milestone "milestone/single-user:default".
Configuring devices.
Using RPC Bootparams for network configuration information.
Attempting to configure interface vnet1...
Skipped interface vnet1
Attempting to configure interface vnet0...
Configured interface vnet0
Requesting System Maintenance Mode
SINGLE USER MODE
#

Le miniroot patché semble fonctionnel. Allez hop, testons avec le flar :

{0} ok boot net - install
Boot device: /virtual-devices@100/channel-devices@200/network@0 File and args: -s
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-23 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.

[…]

Processing profile
- Saving Boot Environment Configuration
- Opening Flash archive
- Validating Flash archive
- Selecting all disks
- Configuring boot device
- Configuring / (any)

ZFS send stream rpool/ROOT/ABE gets extracted to rpool/ROOT/root
ZFS send stream rpool/export gets extracted to rpool/export

Verifying disk configuration
Verifying space allocation

Preparing system for Flash install

Configuring disk (c0d0)
- Creating Solaris disk label (VTOC)
- Creating pool rpool
- Creating swap zvol for pool rpool
- Creating dump zvol for pool rpool

Beginning Flash archive processing

Predeployment processing
16 blocks
32 blocks
16 blocks

No local customization defined

Extracting archive: flar01
Extracted 0.00 MB ( 0% of 11387.00 MB archive)
Extracted 1.00 MB ( 0% of 11387.00 MB archive)
Extracted 2.00 MB ( 0% of 11387.00 MB archive)
Extracted 3.00 MB ( 0% of 11387.00 MB archive)
[…]
Extracted 11384.42 MB ( 99% of 11387.00 MB archive)
Extracted 11385.42 MB ( 99% of 11387.00 MB archive)
Extracted 11386.42 MB ( 99% of 11387.00 MB archive)
Extracted 11387.00 MB (100% of 11387.00 MB archive)
Extraction complete
[…]

Rien de plus simple qu'un petit montage lofs pour contourner le problème dans le script de prepatch du kernel. Astuce valable pour le kernel 147440-23, à voir si dans les versions inférieurs (ou suppérieurs), cette erreur est (ou sera) encore présente.

Ci-joint quelques références sur ce sujet :

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : administration
Ecrire un commentaire - Voir les 0 commentaires

Dimanche 11 novembre 2012 7 11 /11 /Nov /2012 15:29

Happy birthday Sparc et Solaris

25 ans pour Sparc et 20 ans pour Solaris !! Félicitation.

Le hardware Sparc et OS Solaris ont atteint une belle maturité qui je l'espère continuera encore longtemps. En tout cas, depuis le rachat de Sun par Oracle, il semble que l'investissement sur l'architecture Sparc et sur l'OS Solaris sont loin d'être à l'abandon : annonces jusqu'en 2016 (voir la roadmap public). L'arrivée prochaine du Sparc T5 associée à la nouvelle version de Solaris 11 semble très prometteuse. Affaire à suivre.

Quelques sources de lectures en ces jours pluvieux :

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : divers
Ecrire un commentaire - Voir les 0 commentaires

Samedi 16 juin 2012 6 16 /06 /Juin /2012 10:16

Fragmentation de l'Intimate Shared Memory (ISM)

Petit compte rendu sur un problème de performance que je viens de rencontrer sur un serveur Solaris Sparc avec une base de donnée Oracle. Le contexte étant le suivant : temps de réponse dégradés suite au reboot du serveur. Bien entendu, aucun changement entre les deux reboot et pourtant l'application fonctionne moins bien qu'avant.

Commençons par le début :

$ vmstat 1 60

kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s7 s8 s9 s1 in sy cs us sy id
2 2 0 153281392 104614544 4824 7797 16312 457 457 0 0 6 2 0 0 12173 125078 25167 18 9 73
4 1 0 110702776 64484544 8681 26172 36014 0 0 0 0 0 0 0 0 28270 284267 39452 51 45 4
27 2 0 110701000 64466128 8187 25244 33717 0 0 0 0 0 0 0 0 30699 317983 40125 56 43 0
58 4 0 110655752 64437344 6890 35606 35200 0 0 0 0 0 0 0 0 29945 270086 39936 51 46 4
81 2 0 110652760 64419824 2422 4687 21878 0 0 0 0 0 0 0 0 19933 146223 21668 56 42 2
68 1 0 110640232 64442472 3117 7019 36429 0 0 0 0 0 0 0 0 17947 153021 21306 56 40 4
82 2 0 110673872 64459640 3740 19469 15517 0 0 0 0 0 0 0 0 17143 197402 23112 55 45 0
53 1 0 110817840 64541056 16751 85478 37213 0 0 0 0 13 0 0 0 32290 400389 43440 50 49 2
27 1 0 110804904 64526728 9514 25054 29034 0 0 0 0 24 24 24 24 32222 362887 43524 57 41 2
22 3 0 110760264 64497288 8110 10600 27836 0 0 0 0 10 24 24 24 33012 368583 46368 54 42 4
46 1 0 110219560 64480488 5238 9330 16615 0 0 0 0 24 24 24 24 33111 293475 41391 54 45 1
31 2 0 109691888 64462816 6337 5855 35649 0 0 0 0 24 24 24 24 32564 324041 41930 51 47 3
8 1 0 110828328 64515976 7183 15999 60116 7 0 0 0 24 24 24 24 30930 363314 48875 55 37 8
4 3 0 110738808 64452664 4294 4912 33406 0 0 0 0 24 24 24 24 25878 284752 40035 49 43 9

[...]

La runqueue est quelque peu remplie, vous ne trouvez pas ? Normalement l'utilisation système de ce serveur avoisine les 15%. Actuellement nous consommons plus du double. Bizarre !?

En détaillant un peu plus l'utilisation par cpu, j'obient cela :

$ mpstat 1 60

CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 130   2 3928   219    8   16   18    5 152    0    68   36 64   0   0
1   52 17 668688   152   17 514   84 102 119    0 2700   19 78   0   3
2 123 23 875479    80   11 190   41   37 273    0   835   20 78   0   2
3   67 10 5639   186   19 596 108 171 2739    2 4200   45 50   0   5
4   82   0 2238   359   10 715 278 131 315    0 4078   47 52   0   1
5 106   0 3470   191   16 325 120   91 170    1 1498   46 53   0   1
6   81   0 6341   893   24 2110 739 410 174    0 10915   72 25   0   2
7   48   2 4116   198   16 378 103   90 139    0 1809   20 78   0   2
8   30   0 1686   103   18 776   40 128 2272    0 6072   70 20   0 10
9   77   1 2085   106   22 486   32 110 4239    1 5263   35 48   0 17
10   57   1 830   119   25 1760   41 111 1146    1 11804   56 33   0 11
11   50   0 39677   142   40 602   35 125   93    0 3952   67 15   0 18
12   82   0 3574   156   15 607   72 143 298    1 3154   36 49   0 15
13 118   0 1263    96   25 174   37   60 251    0 1072   47 49   0   4
14   66   0 992   146   16 600   57 125   75    0 3470   66 12   0 22
15   53   0 330    87   11 448   12   38   96    0 2328   30 57   0 12
16   57   4 7363   318   36 1543 147 431 124    0 7300   52 24   0 25
17   38   2 10889 10088 9791 1366 142 389 306    0 5889   20 59   0 20
18   61   2 4960   251   33 1051 115 327 119    0 5081   49 32   0 20
19   20   1 4050   235   22 1149 110 281 153    0 5047   28 49   0 23
20   69   0 189652   226   22 579 131 155 224    0 3525   32 61   0   6
21   12   1 1361611    57   16   27    4   13   96    0   131    4 95   0   1
22   88   1 5381   423   38 1049 259 285 601    0 6239   60 30   0 10
23 144   1 5722   374   40 899 223 246 2358    2 6196   41 50   0   8
512   33   2 17331    65   10 102   22   31 499    0   923   12 86   0   2
513   33 19 120216   279   22 717 143 170 106    0 3107   43 55   0   2
514   53 20 14957   582   29 2035 398 480 215    1 9802   46 43   0 11
515    5 13 2871 1303 1218 139   24   32 2545    0   952    6 93   0   1
516   57   0 4672   243   14 475 175 110 170    0 2339   42 57   0   1
517   83   0 2163 1314 1250   23    5    3   84    0    86   25 75   0   0
518 106   1 8336 1001   25 2445 863 415 231    2 11656   65 32   0   3
519   56   0 5720   819   25 1905 655 415 229    1 9969   61 38   0   2
520   45   0 3534   139   36 411   28 141 139    0 1675   43 28   0 29
521   27   2 4369   167   37 677   27 149 184    0 2423   31 24   0 45
522   49   0 2994   128   27 644   20 114 143    0 2822   44 20   0 36
523   52   0 5220   176   27 819   56 151 2977    1 6423   25 38   0 37
524 172   1 310    55    8 304   10   27 233    0 1564   55 32   0 13
525   73   2 1535   123   13 597   46 115   86    0 3898   64 22   0 14
526   77   1 3821   242   29 1059   94 225 202    0 5572   50 28   0 22
527   52   1 2318   234   25 1106   87 234 1026    0 4908   39 25   0 36
528   59   0 4609   248   33 1145   98 285 164    0 5014   38 36   0 26
529   25   0 11442   341   41 1818 149 454   97    0 8854   37 31   0 32
530   33   0 553    81   10    4    5    1   48    0     0   34 66   0   0
531   51   1 6084   393   50 1754 172 468 113    0 7707   43 21   0 36
532   30   0 700781   139   12 263   85   65 135    0 1747   30 68   0   2
533   59   2 368218   183   29 394   73   95 252    0 2593   31 65   0   4
534 250   2 150619   255   32 685 145 228 2420    1 3932   39 59   0   2
535 108   4 906001   134   20 360   59 104 215    0 1804   24 72   0   4

[...]

Le nombre de smtx est anormalement haut. Regardons avec Dtrace ce qui se passe en mode kernel :

# ./hotkernel

Sampling... Hit Ctrl-C to end.
^C

FUNCTION COUNT PCNT
genunix`rctl_set_tearoff 1 0.0%
[...]

unix`idle                        6622   2.8%
SUNW,UltraSPARC-IV              15472   6.6%
unix`default_lock_delay         18426   7.8%
unix`disp_getwork               44618 19.0%
unix`mutex_delay_default       115315 49.0%

Voilà pourquoi le nombre de smtx est élevé. Le temps d'utilisation kernel provient essentiellement de mutex. Voyons qui les génèrent :

# dtrace -n 'profile:::profile-1001hz /arg0/ { @[func(arg0), execname] = count(); }'

[...]

SUNW,UltraSPARC-IV+`gettick      oracle            5062
unix`mutex_enter   oracle        6222
unix`mutex_delay_default         svc.startd        6768
unix`kcage_cageout               pageout           8347
unix`mutex_delay_default         tnslsnr           8811
unix`page_numtopp_nolock         pageout           9325
unix`generic_idle_cpu            sched         9829
unix`idle                        sched            76849
unix`default_lock_delay          oracle           96305
unix`disp_getwork                sched           275834
unix`mutex_delay_default         oracle          573610

Il s'agit des process Oracle. L'analyse de la stack() peut nous en dire un peu plus :

# dtrace -n 'profile:::profile-1001hz /arg0 && execname == "oracle"/ \
{ @[stack()] = count(); } tick-60s { trunc(@,10); exit(0); }'

dtrace: description 'profile:::profile-1001hz ' matched 2 probes
CPU     ID                    FUNCTION:NAME
16 85099                        :tick-60s

[...]
              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_tlb_range_demap+0x88
              unix`hat_unload_callback+0x7dc
              genunix`segvn_unmap+0x28c
              genunix`as_unmap+0xf0
              genunix`munmap+0x78
              unix`syscall_trap+0xac
             5736
[...]
              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_size_tsb+0x4
              unix`sfmmu_check_page_sizes+0x17c
              unix`hat_do_memload+0xf4
              genunix`segvn_faultpage+0x560
              genunix`segvn_fault+0xbf0
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0xd50
              unix`utl0+0x4c
             7342

              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_size_tsb+0x4
              unix`sfmmu_check_page_sizes+0x17c
              unix`hat_unload_callback+0x898
              genunix`segvn_unmap+0x28c
              genunix`as_unmap+0xf0
              mm`mmsegmap+0xa8
              genunix`cdev_segmap+0x60
              specfs`spec_char_map+0x104
              specfs`spec_map+0x94
              genunix`fop_map+0x40
              genunix`smmap_common+0x3ac
              genunix`smmap64+0x80
              unix`syscall_trap+0xac
             8367

              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_tlb_range_demap+0x88
              unix`hat_unload_callback+0x7dc
              genunix`anon_private+0x20c
              genunix`segvn_faultpage+0x7d4
              genunix`segvn_fault+0xbf0
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0xd50
              unix`utl0+0x4c
            12659

              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_size_tsb+0x4
              unix`sfmmu_check_page_sizes+0x17c
              unix`hat_do_memload+0xf4
              genunix`segvn_faultpage+0x32c
              genunix`segvn_fault+0xbf0
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0xd50
              unix`utl0+0x4c
            27669

              unix`mutex_delay_default+0x4
              unix`current_thread+0x164
              unix`default_lock_delay+0x6c
              unix`mutex_vector_enter+0x460
              unix`sfmmu_hat_enter+0x2c
              unix`sfmmu_tsbmiss_exception+0x6c
              unix`utl0+0x4c
            98775

Un des avantages de l'ISM est de diminuer l'impact sur les tables TLB/TSB. Au vu des appels, il semble que cela soit le contraire. L'appel à la fonctions sfmmu_check_page_sizes() est assez étrange : normalement un segment ISM utilise des larges de 4Mo sur Sparc. Alors pourquoi rechercher une taille de page ?

En parcourant le code source d'Opensolaris pour la fonction sfmmu_tsbmiss_exception() on peut lire cela :

/*
* Handle exceptions for low level tsb_handler.
*
* There are many scenarios that could land us here:
*
* If the context is invalid we land here. The context can be invalid
* for 3 reasons: 1) we couldn't allocate a new context and now need to
* perform a wrap around operation in order to allocate a new context.
* 2) Context was invalidated to change pagesize programming 3) ISMs or
* TSBs configuration is changeing for this process and we are forced into
* here to do a syncronization operation. If the context is valid we can
* be here from window trap hanlder. In this case just call trap to handle
* the fault.
*
[...]

Le cas 3 est assez surprenant : un changement de configuration ISM pour un process donné ? Vérifions un peu le mapping mémoire du segment ISM :

# pmap -xs 5514 | more

5514:   ora_pmon_XXXX01
         Address   Kbytes     RSS   Anon   Locked Pgsz Mode   Mapped File
0000000100000000    73728   73728      -        -   4M r-x-- oracle
0000000104800000     8192    8192      -        -    - r-x-- oracle
0000000105000000    20480   20480      -        -   4M r-x-- oracle
[...]

0000000380000000     8192    8192      -     8192   4M rwxsR [ ism shmid=0x3 ]
0000000380800000    16384   16384      -    16384    - rwxsR [ ism shmid=0x3 ]
0000000381800000    16384   16384      -    16384   4M rwxsR [ ism shmid=0x3 ]
0000000382800000     4096    4096      -     4096    - rwxsR [ ism shmid=0x3 ]
0000000382C00000    20480   20480      -    20480   4M rwxsR [ ism shmid=0x3 ]
0000000384000000     4096    4096      -     4096   8K rwxsR [ ism shmid=0x3 ]
0000000384400000    36864   36864      -    36864   4M rwxsR [ ism shmid=0x3 ]
0000000386800000       16      16      -       16    - rwxsR [ ism shmid=0x3 ]
0000000386804000        8       8      -        8   8K rwxsR [ ism shmid=0x3 ]
0000000386806000        8       8      -        8    - rwxsR [ ism shmid=0x3 ]
0000000386808000       24      24      -       24   8K rwxsR [ ism shmid=0x3 ]
000000038680E000       32      32      -       32    - rwxsR [ ism shmid=0x3 ]
0000000386816000       16      16      -       16   8K rwxsR [ ism shmid=0x3 ]
000000038681A000        8       8      -        8    - rwxsR [ ism shmid=0x3 ]
[...]
000000038683A000        8       8      -        8   8K rwxsR [ ism shmid=0x3 ]
000000038683C000       24      24      -       24    - rwxsR [ ism shmid=0x3 ]
0000000386842000       16      16      -       16   8K rwxsR [ ism shmid=0x3 ]
0000000386846000        8       8      -        8    - rwxsR [ ism shmid=0x3 ]
0000000386848000        8       8      -        8   8K rwxsR [ ism shmid=0x3 ]

[...]

Quelque chose cloche !! Pour le même segment ISM nous avons une multitude de pages de tailles différentes mais surtout l'allocation du segment ISM est complètement fragmentée. Les sessions Oracle perdent un temps important dans la gestion de mémoire ISM. L'origne reste cependant inconnu !

L'ouverture d'un call au support Oracle confirme bien cette analyse (merci Alain). Cependant rien de bien précis concernant l'origine. Lors d'une activitée mémoire soutenue sur un serveur, ce bug peut se produire mais dans notre cas le serveur venait de rebooter. S'agissant d'une base Oracle 10.2.0.4, l'option NUMA est activée. Du coup le segment ISM est découpé entre les différents lgrp disponibles sur le serveur. La recherche de page par sous segment ISM lors de l'activation du NUMA peut poser un peu plus de problème (cela fonctionnait avant non ?). La taille de l'ARC peut aussi influencer lors de la recherche des pages pour la création de l'ISM. Mystère...

Ci-joint quelques références sur ce sujet :

Chapitre 12 "Hardware Address Translation" dans Solaris Internals
Chapitre 16 "Support for NUMA and CMT Hardware" dans Solaris internals
Architecture NUMA dans Solaris (10 et 11)
ISM sous Solaris 10x86 (Partie 1, Partie 2 et Workarounds)
Optimizing Applications with Large Working Sets in Solaris 8 and 9
Opensolaris code : hat_sfmmu.c
Opensolaris code : hat.h

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 0 commentaires

Mardi 1 mai 2012 2 01 /05 /Mai /2012 19:13

Fusion IO in a nutshell

Petit retour sur la mise oeuvre d'une carte Fusion IO sous Solaris 10x64. J'ai été amené à tester un des produit de la gamme Fusion IO pour répondre à différentes problèmatiques liées aux bases de données Oracle et Sybase (les différents tests ont été effectués avec la carte ioDrive Duo à 1,28 To).

L'installation du driver n'a rien de bien sorcier (un simple pkgadd, merci du peu). Il se peut que le module ne soit pas chargé automatiquement après l'installation du package, il vous suffit alors d'utiliser add_drv pour le faire. Une fois le package installé et le module chargé, vous pouvez utiliser votre carte.

# cd /opt/fusionio/bin
# ./fio-status -a

Found 2 ioDrives in this system with 1 ioDrive Duo
Fusion-io driver version: 2.3.1 build 123

Adapter: ioDrive Duo
    Fusion-io ioDrive Duo 1.28TB, Product Number:FS3-202-641-CS SN:100364
    ioDrive Duo HL, PN:00190000107, Mfr:004, Date:20110104
    External Power: NOT connected
    Powerloss protection: available
    PCIE Bus voltage: avg 12.20V, min 12.11V, max 12.21V
    PCIE Bus current: avg 0.91A, max 2.76A
    PCIE Bus power: avg 11.07W, max 27.49W
    PCIE Power limit threshold: 24.75W
    Connected ioDimm modules:
     fct0: Fusion-io ioDrive Duo 1.28TB, Product Number:FS3-202-641-CS SN:72376
     fct1: Fusion-io ioDrive Duo 1.28TB, Product Number:FS3-202-641-CS SN:72417

fct0 Attached as 'fioa' (block device)
      Fusion-io ioDrive Duo 1.28TB, Product Number:FS3-202-641-CS SN:72376
      ioDIMM3 640GB MLC, PN:00276700501, Mfr:004, Date:20110103
      Located in slot 1 Lower of ioDrive Duo SN:100364
      Powerloss protection: protected

PCI:0c:00.0

      Vendor:1aed, Device:1005, Sub vendor:1aed, Sub device:1010
      Firmware v5.0.7, rev 101971
      640.00 GBytes block device size, 812 GBytes physical device size
      Format: block, v300, 1,250,001,920 sectors, 512 bytes per sector
      Error correction: 39 bits per 960 bytes
      FPGA ID:0 Format UID:000000011ab80132db170041f8755400
      Internal temperature: 49.7 degC, max 54.1 degC
      Board temperature: 40 degC
      Internal voltage: avg 0.996V, max 1.005V
      Aux voltage: avg 2.429V, max 2.429V
      Media status: Healthy; Reserves: 100.00%, warn at 10.00%
      Lifetime data volumes:
        Physical bytes written: 238,962,192,171,536
        Physical bytes read   : 233,379,513,217,664
        RAM usage:
           Current: 206,100,480 bytes
         Peak   : 275,838,976 bytes

fct1 Attached as 'fiob' (block device)
      Fusion-io ioDrive Duo 1.28TB, Product Number:FS3-202-641-CS SN:72417
      ioDIMM3 640GB MLC, PN:00276700501, Mfr:004, Date:20110103
      Located in slot 0 Upper of ioDrive Duo SN:100364
      Powerloss protection: protected
      PCI:0b:00.0
      Vendor:1aed, Device:1005, Sub vendor:1aed, Sub device:1010
      Firmware v5.0.7, rev 101971
      640.00 GBytes block device size, 812 GBytes physical device size
      Format: block, v300, 1,250,001,920 sectors, 512 bytes per sector
      Error correction: 39 bits per 960 bytes
      FPGA ID:0 Format UID:000000011ae10132db170041f8755400
      Internal temperature: 54.6 degC, max 59.6 degC
      Board temperature: 44 degC
      Internal voltage: avg 1.017V, max 1.025V
      Aux voltage: avg 2.435V, max 2.438V
      Media status: Healthy; Reserves: 100.00%, warn at 10.00%
      Lifetime data volumes:
        Physical bytes written: 247,334,121,450,136
        Physical bytes read   : 244,476,258,760,136
        RAM usage:
         Current: 209,283,072 bytes
           Peak   : 277,673,984 bytes

Quelques précausions avant de commencer à l'utiliser la carte : mettre à jour le firmware de la carte (fio-update-iodrive) et la formater avant utilisation.

# ./fio-detach /dev/fct0
Detaching: [====================] (100%) |

# ./fio-detach /dev/fct1
Detaching: [====================] (100%) |

# ./fio-format /dev/fct0
Creating a standard block device of size 640.00GBytes (596.05GiBytes).
Using block (sector) size of 512 bytes.

WARNING: Formatting will destroy any existing data on the device!
Do you wish to continue [y/n]? y
Formatting: [====================] (100%) \
Format successful.

# ./fio-format /dev/fct1
Creating a standard block device of size 640.00GBytes (596.05GiBytes).
Using block (sector) size of 512 bytes.

WARNING: Formatting will destroy any existing data on the device!
Do you wish to continue [y/n]? y
Formatting: [====================] (100%) |
Formatting: [====================] (100%)
Format successful.

# ./fio-attach /dev/fct0
Attaching: [====================] (100%) -
fioa

# ./fio-attach /dev/fct1
Attaching: [====================] (100%) -
fiob

Nous voiçi donc avec une unité de stockage prête à l'emploi. A vous de choisir le LVM (SVM, ZFS) selon vos uses et coutumes. Pour les amateurs de VxVM sous Solaris, je pense qu'il n'y a pas de problèmes (les tests restent à être réalisés, je susi preneur de l'information).

Ci-joint quelques tests comparatifs entre du stockage SAN et la carte Fusion IO. Tous les tests ont été réalisés avec l'utilitaire filebench.

Configuration SAN :

Solaris s10x_u10wos_17b (kernel 147441-11)
Stockage EMC VMAX (52 Luns de 34 Go)
VxVM (stripe 4 colonnes - stripe unit 64 Ko)
UFS largefile
Option de montage directio et non directio

Configuration Fusion IO :

Solaris s10x_u10wos_17b (kernel 147441-11)
Stockage Fusion IO
ZFS (avec compression)
Dataset (logbias à throuput)

Résultats :

Configuration SAN sans directio

filebench> load oltp
[...]
filebench> set $dir=/filebench
filebench> set $iosize=8192
filebench> set $filesize=2147483648
filebench> run runtime
[...]
9894: 2585.561: IO Summary: 87982 ops, 1466.331 ops/s, (741/719 r/w), 11.2mb/s, 2890us cpu/op, 243.7ms latency
9894: 2585.561: Shutting down processes
9894: 2588.876: Deleting ISM...

Configuration SAN avec directio

filebench> load oltp
[...]
filebench> set $dir=/filebench
filebench> set $iosize=8192
filebench> set $logfilesize=2147483648
filebench> run runtime
[...]
12702: 2205.474: IO Summary: 485747 ops, 8095.346 ops/s, (4038/4016 r/w), 62.9mb/s, 523us cpu/op, 13.6ms latency
12702: 2205.474: Shutting down processes
12702: 2207.606: Deleting ISM...

Configuration Fusion IO

filebench> load oltp
[...]
filebench> set $dir=/fusionio
filebench> set $iosize=8192
filebench> set $filesize=2147483648
filebench> run runtime
[...]
24859: 2337.767: IO Summary: 2287573 ops, 38045.769 ops/s, (18937/18914 r/w), 296.9mb/s, 223us cpu/op, 8.4ms latency
24859: 2337.767: Shutting down processes
24859: 2339.914: Deleting ISM...

Les résultats parlent d'eux-mêmes, non ? Le débit sur la carte Fusion IO avoisine les 300 Mb/s ?! Le fait d'utiliser de ZFS compressé permet en plus d'augmenter de manière significative la capacité de stockage de la carte (sans altérer ses incroyables capacités).

Juste un petit bémol, sur une infrastructure de production, il est conseillé d'avoir une solution de secours. Avec ce type de configuration, l'utilisation d'outils de clustering classique ne permettent pas une bascule efficace (récupération des données entre les deux serveurs). Il faut donc se poser la question suivante : Comment répliquer les données ? Il faut donc mettre en oeuvre d'autres outils : par exemple Dataguard pour Oracle ou des outils de réplication de données sur IP comme AVS.

Ci-joint quelques références sur ce sujet :