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

 

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 :

 

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

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

 

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 :

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

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

 

 

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 :

 

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

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

 

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 :

 

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

Jeudi 22 mars 2012 4 22 /03 /Mars /2012 20:48

 

Le 5 avril prochain Oracle France organise l'évènement : Oracle SPARC Supercluster, Performance, Souplesse et Ouverture.

 

Le SuperCluster est une solution totalement intégrée conçue pour héberger, en mode hautement disponible et avec des performances extrêmes, vos applications, vos bases données et vos middleware au sein d'un même châssis. Sa capacité multi-fonctions (support de multiples versions de bases de données, de différentes typologies d'applications...) lui confère une souplesse d'utilisation unique.

 

L'ouverture de SPARC SuperCluster (connexion au SAN, évolutivité verticale et horizontale...) rend son intégration aisée au sein de votre infrastructure existante. Le SPARC SuperCluster est notamment composé de serveurs T4-4, d'un réseau Infiniband, d'une applicance Oracle ZFS Storage et de Solaris 11.

 

Je vous invite donc rapidement à vous inscrire à cet évènement via l'agenda du GUSES ou directement sur le site Oracle pour décourvrir dans le détail cette nouvelle machine intégrée.

 

 

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

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

Jeudi 15 mars 2012 4 15 /03 /Mars /2012 17:32

 

Lors des deux précédents articles (disponibles ici et ), j'ai évoqué à plusieurs reprises la notion de NUMA sans trop la détailler. NUMA (NonUniform Memory Access) est devenue l'une des architectures matérielles la plus utilisée dans la conception des serveurs. Je profite donc de cet article pour revenir sur son intégration dans Solaris (notamment les versions 10 et 11).

 

En théorie, une machine NUMA est composée d'une ou plusieurs nodes disposant chacune d'un certain nombre de CPU(s) et d'une certaine quantité de mémoire. Toutes les nodes sont interconnectées entre elles et partagent l'intégralité mémoire de la machine. Les temps d'accès mémoire contenue dans une node sont inférieurs aux temps d'accès mémoire contenue dans une node distante (modèle de latence).

 

Un modèle de latence consiste le plus souvent à un ou plusieurs locality groups (lgrps). Chaque lgrp est constitué :

  • d'une ou plusieurs CPU(s)
  • d'une ou plusieurs pages de mémoire physiques

lgroup

 

A noter qu'il existe plusieurs modèles de latence plus ou moins complexes (différents niveaux de latence).

 

Solaris est "aware" de l'architecture matérielle NUMA : les différentes nodes sont des éléments connus du système Solaris. L'association mémoire / CPUs est connue de Solaris sous la forme de groupe de localité (locality group).

 

Le framework MPO (Memory Placement Optimization) est un composant essentiel à l'architecture NUMA. Pour une application en cours de fonctionnement, le système Solaris tente de l'exécuter sur une CPU la plus proche de la mémoire pour minimiser le plus possible les temps d'accès à celle-ci.

 

Quelques notions importantes à connaître :

  • Pour chaque nouveau thread un locality group est sélectionné (home lgrp)
  • L'algorithme d'ordonnancement tentera d'exécuter un thread sur une des CPUs de son home lgrp
  • La classe d'ordonnancement RT n'est pas prise en compte dans cet algorithme

Un thread peut changer de home lgrp uniquement si :

  • Le locality group est détruit
  • Le thread est binder sur une autre CPU d'un autre locality group

Plusieurs paramètres sont disponibles pour modifier le comportement des lgrps. Voir la section suivante : Locality Group Parameters dans Oracle Solaris Tunable Parameters Reference Manuel.

 

 

Maintenant, passons un peu à la pratique... Pour connaître le nombre de lgrps disponible sur un système, il existe deux méthodes : en utilisant la commande kstat ou en passant par mdb :

 

# kstat -m lgrp  
module: lgrp             instance: 1    
name:   lgrp1            class:    misc
    alloc fail           294068397
    cpus                 8
    crtime               343.726918435
    default policy       0
    load average         11296
    lwp migrations       1309
    next-seg policy      0
[...]


# mdb -k

Loading modules: [...]

> ::walk cpu |::print cpu_t cpu_lpl |::print lgrp_t lgrp_id !sort -u
lgrp_id = 0x6bdd
lgrp_id = 0x8356
lgrp_id = 0x840b
lgrp_id = 0xa232

 

La macro lgrp disponible dans mdb permet d'obtenir bien plus d'informations sur les lgrps dont notamment le nombre de CPUs et leurs répartitions. Attention cette macro n'est pas disponible dans toutes les updates de Solaris 10 :

 

# mdb -k
Loading modules: [...]
> ::lgrp
 LGRPID             ADDR           PARENT    PLATHAND   #CPU    CPUS
      0 fffffffffbc20580                0     DEFAULT      0     
      1 fffffffffbc0d440 fffffffffbc20580           0      8    0-7
      2 fffffffffbc0d4a8 fffffffffbc20580           1      8    8-15
      3 fffffffffbc0d510 fffffffffbc20580           2      8    16-23
      4 fffffffffbc0d578 fffffffffbc20580           3      8    24-31

 

Les statistiques des lgrps sont disponibles facilement via la commande kstat. Par exemple pour le lgrp 3, il  suffit de saisir la commande suivante :

 

$ kstat -m lgrp -i 3
module: lgrp                       instance: 3    
name:   lgrp3                      class:    misc
    alloc fail                     557701
    cpus                           8
    crtime                         345.278084135
    default policy                 0
    load average                   48125
    lwp migrations                 41345
    next-seg policy                0
    next-touch policy              9959223943
    pages avail                    33554432
    pages failed to mark           0
    pages failed to migrate from   0
    pages failed to migrate to     0
    pages free                     6976717
    pages installed                33554432
    pages marked for migration     0
    pages migrated from            0
    pages migrated to              0
    random policy                  5496062
    round robin policy             0
    snaptime                       8170819.92639302
    span process policy            0
    span psrset policy             0

 

Pour obtenir le home lgrp d'un thread en cours d'exécution, il suffit d'utiliser mdb (l'adresse du lgrp est stockée dans la structure kthread_t) :

 

# mdb -k

Loading modules: [...]

> 0t26116::pid2proc |::walk thread |::print kthread_t t_lpl |::print struct lgrp_ld lpl_lgrpid

lpl_lgrpid = 0x4

 

Lors de la création d'un thread, il suffit d'utiliser le one-liner Dtrace ci-dessous pour connaître rapidement son home lgrp :

 

# dtrace -qn 'thread_create:return { printf("Created thread (PID %d LWP %d) with home lgroup %d\n", pid, tid, curthread->t_lpl->lpl_lgrpid); }"
Created thread (PID 26539 LWP 1) with home lgroup 3
Created thread (PID 26743 LWP 1) with home lgroup 2
Created thread (PID 26745 LWP 1) with home lgroup 4
Created thread (PID 5913 LWP 1) with home lgroup 3
Created thread (PID 26745 LWP 1) with home lgroup 4
Created thread (PID 18609 LWP 26478) with home lgroup 3
Created thread (PID 18609 LWP 26478) with home lgroup 3
Created thread (PID 26757 LWP 1) with home lgroup 4
Created thread (PID 2473 LWP 7) with home lgroup 4
Created thread (PID 26754 LWP 1) with home lgroup 4
^C
Created thread (PID 26763 LWP 1) with home lgroup 1
Created thread (PID 26771 LWP 1) with home lgroup 2

 

En théorie, un thread sera le plus souvent exécuté sur les CPUs disponibles dans son home lgrp. Pour vérifier cela, j'utilise un petit script Dtrace (inspiré du script getlgrp.d disponible dans Solaris Internals - attention j'ai du modifié quelque peu le code pour qu'il fonctionne sur les dernières versions de Solaris 10) :

 

# mdb -k

Loading modules: [...]

> 0t11517::pid2proc |::walk thread |::print kthread_t t_lpl |::print struct lgrp_ld lpl_lgrpid
lpl_lgrpid = 0x4

 

# ./lgrp.d 11517
^C
Threads CPUs and lgrps for PID 11517

TID   LGRP     CPUID    COUNT  
================================
1     2        8        2      
1     1        2        4      
1     1        7        5      
1     1        3        6      
1     1        5        6      
1     1        6        6      
1     2        9        6      
1     2        10       6      
1     2        13       6      
1     1        0        7      
1     2        11       7      
1     1        4        8      
1     2        12       8      
1     2        15       8      
1     1        1        9      
1     3        16       9      
1     3        20       9      
1     3        22       9      
1     2        14       10     
1     3        21       10     
1     3        17       11     
1     3        23       11     
1     3        19       12     
1     3        18       13     
1     4        26       216    
1     4        31       226    
1     4        28       246    
1     4        24       247    
1     4        29       298    
1     4        25       308    
1     4        27       342    
1     4        30       370 

 

Dans cet exemple, le processus 11517 contient un seul lwp. On constate que celui-ci est exécuté majoritairement sur les différentes CPUs du lgrp 4. L'algorithme du MPO effectue correctement son travail pour favoriser l'exécution du processus sur son home lgrp.

 

Lors de la création d'un fils (processus ou thread), le système Solaris tente de sélectionner une CPU dans le home lgrp du père. Cependant si les ressources souhaitées (notamment mémoire) ne sont pas disponibles, le système choisit alors un nouveau home lgrp pour ce fils.

 

Pour observer ces évènements, j'utilise la fonction lgrp_move_thread() :

 

# ./lgrpmove.d

Thread 1 (pid 13222) from Home lgrp 4 rehomed to New lgrp 3
Thread 1 (pid 18776) from Home lgrp 1 rehomed to New lgrp 2
Thread 1 (pid 18774) from Home lgrp 1 rehomed to New lgrp 4
Thread 864 (pid 18800) from Home lgrp 4 rehomed to New lgrp 2
Thread 1 (pid 18816) from Home lgrp 3 rehomed to New lgrp 1
Thread 1 (pid 18822) from Home lgrp 2 rehomed to New lgrp 1
Thread 1 (pid 15869) from Home lgrp 4 rehomed to New lgrp 3
Thread 1 (pid 15944) from Home lgrp 2 rehomed to New lgrp 1
Thread 1 (pid 18843) from Home lgrp 2 rehomed to New lgrp 3
Thread 1 (pid 15869) from Home lgrp 4 rehomed to New lgrp 3
Thread 1 (pid 15869) from Home lgrp 4 rehomed to New lgrp 3
Thread 1 (pid 18864) from Home lgrp 4 rehomed to New lgrp 1
Thread 1 (pid 15944) from Home lgrp 2 rehomed to New lgrp 1
Thread 1 (pid 18855) from Home lgrp 3 rehomed to New lgrp 2
Thread 1 (pid 18880) from Home lgrp 2 rehomed to New lgrp 3

^C

Thread 1 (pid 18863) from Home lgrp 1 rehomed to New lgrp 3
Thread 1 (pid 18857) from Home lgrp 4 rehomed to New lgrp 3

 

Dans Solaris 11, nous disposons deux nouvelles commandes lgrpinfo et plgrp pour consulter et changer le home lgrp d'un thread (Je vous encourage à consulter avec attention les pages de manuels de ces deux nouvelles commandes).

 

La commande lgrpinfo affiche toutes les informations sur les lgrps :

 

# lgrpinfo
lgroup 0 (root):
        Children: 1 2
        CPUs: 0-11
        Memory: installed 48G, allocated 2.8G, free 45G
        Lgroup resources: 1 2 (CPU); 1 2 (memory)
        Latency: 70197
lgroup 1 (leaf):
        Children: none, Parent: 0
        CPUs: 0 2 4 6 8 10
        Memory: installed 24G, allocated 915M, free 23G
        Lgroup resources: 1 (CPU); 1 (memory)
        Load: 0.168
        Latency: 48058
lgroup 2 (leaf):
        Children: none, Parent: 0
        CPUs: 1 3 5 7 9 11
        Memory: installed 24G, allocated 1.9G, free 22G
        Lgroup resources: 2 (CPU); 2 (memory)
        Load: 0.0259
        Latency: 48058

 

Pour obtenir le home lgrp d'un thread, il suffit simplement simplement de saisir la commande plgrp :

 

# plgrp $$
     PID/LWPID    HOME
    2947/1        2    

 

L'exécution d'une application bénéficiant du meilleur placement est un axe d'optimisation de plus en plus important. Plusieurs recherches vont dans ce sens : après MPO dans Solaris 9 et 10, Solaris 11 utilise aussi des algorithmes de placements pour les I/O (NUMA I/O). Affaire à suivre...

 

 

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

 

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

Présentation

Informations personnelles

  • Passionné d'informatique, je travaille actuellement comme expert système Solaris. Vous trouverez plus de renseignements à mon sujet sur mon profil Linkedin.

Flux RSS

  • Flux RSS des articles

Recherche

Calendrier

Avril 2014
L M M J V S D
  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        
<< < > >>
Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Signaler un abus - Articles les plus commentés