Overblog
Suivre ce blog
Administration Créer mon blog
25 août 2011 4 25 /08 /août /2011 22:06

 

Comment comprendre les problématiques IO quand on ne dispose pas de serveurs de tests ? Et même si vous en avez, la charge est elle représentative ? Pas évident... non ? Et bien si, filebench est là pour nous aider. Ce petit outil permet de simuler différents types d'activités sur le système de fichiers et ainsi nous permettre de mesurer la performance de nos systèmes de fichiers.

 

Petite démonstration de l'outil sur ma VBox en Solaris 11...

 

gloumps@zlap:-$ pkg info filebench
          Name: benchmark/filebench
       Summary: FileBench
   Description: FileBench Commands, Workloads, Scripts, and Config Files
      Category: Development/System
         State: Installed
     Publisher: solaris
       Version: 0.5.11
 Build Release: 5.11
        Branch: 0.151.0.1
Packaging Date:  4 novembre 2010 23:05:42 
          Size: 750.02 kB
          FMRI: pkg://solaris/benchmark/filebench@0.5.11,5.11-0.151.0.1:20101104T230542Z

 

gloumps@zlap:~$ ls -l /usr/benchmarks/filebench
total 7
drwxr-xr-x 4 root bin  6 2011-03-12 17:17 bin
drwxr-xr-x 2 root bin 11 2011-03-12 17:17 config
drwxr-xr-x 2 root bin  4 2011-03-12 17:17 scripts
drwxr-xr-x 2 root bin 48 2011-03-12 17:17 workloads

 

Toutes les types de workloads présentes sont paramérables. Par exemple pour simuler des lectures séquentielles sur un système de fichiers vous pouvez utilser la workload "filemicro_seqread".

 

gloumps@zlap:~$ su -
Password: 
Oracle Corporation      SunOS 5.11      snv_151a        November 2010

root@zlap:~#
root@zlap:~# cd /usr/benchmarks/filebench/bin
 

root@zlap:~# ./go_filebench 
FileBench Version 1.4.8
Bad terminal type: "xterm-256color". Will assume vt100.
filebench> help
 1353: 2.784: load <personality> (ls /usr/benchmarks/filebench/workloads for list) 

 

filebench> load filemicro_seqread
 1429: 83.956: FileMicro-SeqRead Version 2.1 personality successfully loaded
 1429: 83.956: Usage: set $dir=<dir>
 1429: 83.956:        set $cached=<bool>    defaults to false
 1429: 83.956:        set $filesize=<size>  defaults to 1073741824
 1429: 83.956:        set $iosize=<size>    defaults to 1048576
 1429: 83.956:        set $nthreads=<value> defaults to 1
 1429: 83.956:  
 1429: 83.956:        run runtime (e.g. run 60)

 

 

Pour lancer le workload il faut indiquer obligatoire le système de fichiers. Pour cette démonstration, j'ai assigné un nouveau disque à ma VBox que j'ai introduit dans un pool ZFS.

 

 

gloumps@zlap:~$ zpool list       
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
dpool  15,9G  1,00G  14,9G     6%  1.00x  ONLINE  -
rpool  19,9G  3,05G  16,8G    15%  1.00x  ONLINE  -

gloumps@zlap:~$ zfs list -r dpool
NAME    USED  AVAIL  REFER  MOUNTPOINT
dpool  1,00G  14,6G  1,00G  /data1

 

gloumps@zlap:~$ cd /data1
gloumps@zlap:~$ ls
gloumps@zlap:~$

 

Revenons à la fenêtre de filebench... Après quelques modifications, on lance le test

 

filebench> set $dir=/data1
filebench> set $filesize=2147483648
filebench> set $iosize=8192
filebench>

filebench> run
 2259: 421.762: Creating/pre-allocating files and filesets
 2259: 421.764: File largefile: mbytes=2048
 2259: 421.788: Removed any existing file largefile in 1 seconds
 2259: 421.788: making tree for filset /data1/largefile
 2259: 421.789: Creating file largefile...
 2259: 507.754: Preallocated 1 of 1 of file largefile in 86 seconds
 2259: 507.754: waiting for fileset pre-allocation to finish
 2259: 507.755: Starting 1 filereader instances
 2330: 508.022: Starting 1 filereaderthread threads
 2259: 509.022: Running...

 

Pendant que le filebench exécute cette workloads, examinons un peu ce qui se passe sur le système...

 

gloumps@zlap:/data1$ iostat -Mxnzt 3
                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  585,3    0,0   73,2    0,0  6,9  3,0   11,8    5,1 100 100 c9t0d0

                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
    0,3    0,0    0,0    0,0  0,0  0,0    0,0    1,9   0   0 c7d0
  561,6    6,7   70,2    0,0  6,9  3,0   12,2    5,3 100 100 c9t0d0

 

                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
    0,0   41,3    0,0    0,4  0,1  0,1    1,5    1,3   2   3 c7d0
  551,3    1,7   68,9    0,0  6,9  3,0   12,5    5,4 100 100 c9t0d0

                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
    1,0    0,0    0,1    0,0  0,0  0,0    0,0    1,1   0   0 c7d0
  602,8    0,0   75,4    0,0  6,9  3,0   11,5    5,0 100 100 c9t0d0

                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
    0,3   46,3    0,0    0,5  0,2  0,1    5,1    2,8   6   7 c7d0
  567,0    0,0   70,9    0,0  6,9  3,0   12,2    5,3 100 100 c9t0d0

^C

 

root@zlap:/opt/DTT/FS# ./rfileio.d

Read IOPS, top 20 (count)
/dev/pts/5                                                logical          1
/lib/ld.so.1                                              logical          2
/usr/bin/hostname                                         logical          5
/data1/largefile/00000001/00000001                       physical          6
/devices/pseudo/clone@0:ptm                               logical          7
/data1/largefile/00000001/00000001                        logical      44991
/devices/pseudo/random@0:urandom                          logical      44992
/proc/2330/lwp/2/lwpusage                                 logical      89984

 

Read Bandwidth, top 20 (bytes)
/lib/ld.so.1                                              logical        212
/usr/bin/hostname                                         logical        317
/devices/pseudo/clone@0:ptm                               logical       1273
/devices/pseudo/random@0:urandom                          logical     359936
/data1/largefile/00000001/00000001                       physical     786432
/proc/2330/lwp/2/lwpusage                                 logical   45351936
/data1/largefile/00000001/00000001                        logical  368558080

 

De retour sur la fenêtre filebench, on constate le résulat du test

 

[...]

 2259: 569.066: Run took 60 seconds...
 2259: 569.069: Per-Operation Breakdown

seqread-file   9211ops/s  72.0mb/s      0.1ms/op       26us/op-cpu

 2259: 569.069: 
IO Summary: 553027 ops, 9210.8 ops/s, (9211/0 r/w) 72.0mb/s, 41us cpu/op, 0.1ms latency
 2259: 569.069: Shutting down processes

[...]

 

Sans évoquer l'aspect bench du logiciel, l'utilisation de Filebench pour comprendre le fonctionnement des IO dans Solaris 10 et Solaris 11 est tout à fait possible (lorsque je parle d'IO, j'inclue bien évidemment le système de fichiers). Vous pourrez adapter facilement vos scripts Dtrace et utiliser tous les existants selon vos besoins.

 

Les sources étant disponibles, il est possible (je pense) de le compiler et donc l'utiliser sur d'autres types d'OS (des ports existes pour FreeBSD et Linux). Par contre l'association avec Dtrace est uniquement possible sous FreeBSD (et Mac bien évidemment).

 

Published by gloumps - dans dtrace
commenter cet article
7 novembre 2010 7 07 /11 /novembre /2010 17:46

 

Comment faire avec Dtrace pour calculer le nombre de processus initié par un démon sur une période donnée ? Deux providers répondent à cette problématique : le provider profile et le provider tick. La différence entre ces deux providers est la suivante : profile se déclenche à chaque intervalle défini sur chaque CPU alors que le provider tick se déclenche que sur une seule CPU à chaque intervalle (La CPU concernée peut changer).

 

1er exemple avec le provider tick. J'utilise le démon sshd (son pid correspond à 449).

# cat timer-tick.d
#!/usr/sbin/dtrace -qs

proc:::create
/ pid == 449 /
{
        @counts["sshd fork"] = count();
}

tick-1m
{
        exit(0);
}

 

On vérifie le résultat

# ptime ./timer-tick.d
sshd fork  3

real     1:00.473
user        0.205
sys         0.277

 

2ème exemple avec le provider profile. J'utilise toujours le démon sshd (toujours le même pid).

# cat timer-tick.d
#!/usr/sbin/dtrace -qs

 

proc:::create
/ pid == 449 /
{
        @counts["sshd fork"] = count();
}

profile-1m

{
        exit(0);
}

 

On vérifie de nouveau le résultat

# ptime ./timer-profile.d
sshd fork  5

real     1:00.477
user        0.206
sys         0.261

 

Cet article est un petit clin d'oeil à une question posée par un collègue. 

Published by gloumps - dans dtrace
commenter cet article
1 décembre 2009 2 01 /12 /décembre /2009 23:04

 

Amélioration du script Dtrace sig.d, pour permettre d'afficher un plus grand nombre d'informations. Ca ressemble à cela :

 

#!/usr/sbin/dtrace -qs

proc:::signal-send
{
printf("%Y %s(pid:%d uid:%d) is sending signal %d to %s\
(pid:%d ppid:%d uid:%d)\n", walltimestamp,execname,\
pid,uid,args[2],args[1]->pr_fname,args[1]->pr_pid,\
args[1]->pr_ppid,args[1]->pr_uid);
}

 

Pas très compliqué à faire... Ce petit script Dtrace m'a permis de prouver que l'arrêt brutale d'une application ne provenait pas du système mais de l'application elle-même.

Published by gloumps - dans dtrace
commenter cet article
1 décembre 2009 2 01 /12 /décembre /2009 22:45

 

Comme savoir si l'on utilise correctement les appels "directio" ? Avec un petit script Dtrace, il est possible de visualiser facilement les appels systèmes et ansi vérifier correctement ce que fait Solaris. Ci-joint le petit script D qu'il suffit de modifier au besoin...

 

#!/usr/sbin/dtrace -s
#pragma D option flowindent

fbt:ufs:ufs_directio_read:entry
/pid == $1/
{
        self->ts[probefunc] = timestamp;
}

fbt:ufs:ufs_directio_read:return
/pid == $1 && self->ts[probefunc] != 0/
{
        self->duration[probefunc] = (timestamp - self->ts[probefunc])/1000;
}

fbt:ufs:ufs_directio_read:
/pid == $1/
{
        trace(self->duration[probefunc]);
        self->duration[probefunc] = 0;
}

 

Bien entendu, il y a plusieurs façon de faire. Merci de me l'indiquer, je suis preneur.

Published by gloumps - dans dtrace
commenter cet article