BenchmarkingTests.xml

   1 <?xml version='1.0' encoding='UTF-8'?><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="benchmarkingtests">
   2   <title xml:id="benchmarkingtests.title">Benchmarking Lustre File System Performance (Lustre I/O
   3     Kit)</title>
   4   <para>This chapter describes the Lustre I/O kit, a collection of I/O
   5   benchmarking tools for a Lustre cluster.  It includes:</para>
   6   <itemizedlist>
   7     <listitem>
   8       <para><xref linkend="dbdoclet.50438212_44437"/></para>
   9     </listitem>
  10     <listitem>
  11       <para><xref linkend="dbdoclet.50438212_51053"/></para>
  12     </listitem>
  13     <listitem>
  14       <para><xref linkend="dbdoclet.50438212_26516"/></para>
  15     </listitem>
  16     <listitem>
  17       <para><xref linkend="dbdoclet.50438212_85136"/></para>
  18     </listitem>
  19     <listitem>
  20       <para><xref linkend="mds_survey_ref"/></para>
  21     </listitem>
  22     <listitem>
  23       <para><xref linkend="dbdoclet.50438212_58201"/></para>
  24     </listitem>
  25   </itemizedlist>
  26   <section xml:id="dbdoclet.50438212_44437">
  27       <title>
  28           <indexterm><primary>benchmarking</primary><secondary>with Lustre I/O Kit</secondary></indexterm>
  29           <indexterm><primary>profiling</primary><see>benchmarking</see></indexterm>
  30           <indexterm><primary>tuning</primary><see>benchmarking</see></indexterm>
  31           <indexterm><primary>performance</primary><see>benchmarking</see></indexterm>
  32
  33           Using Lustre I/O Kit Tools</title>
  34     <para>The tools in the Lustre I/O Kit are used to benchmark Lustre file system hardware and
  35       validate that it is working as expected before you install the Lustre software. It can also be
  36       used to to validate the performance of the various hardware and software layers in the cluster
  37       and also to find and troubleshoot I/O issues.</para>
  38     <para>Typically, performance is measured starting with single raw devices and then proceeding to groups of devices. Once raw performance has been established, other software layers are then added incrementally and tested.</para>
  39     <section remap="h3">
  40       <title>Contents of the Lustre I/O Kit</title>
  41       <para>The I/O kit contains three tests, each of which tests a progressively higher layer in
  42         the Lustre software stack:</para>
  43       <itemizedlist>
  44         <listitem>
  45           <para><literal>sgpdd-survey</literal> - Measure basic &apos;bare metal&apos; performance
  46             of devices while bypassing the kernel block device layers, buffer cache, and file
  47             system.</para>
  48         </listitem>
  49         <listitem>
  50           <para><literal>obdfilter-survey</literal> - Measure the performance of one or more OSTs
  51             directly on the OSS node or alternately over the network from a Lustre client.</para>
  52         </listitem>
  53         <listitem>
  54           <para><literal>ost-survey</literal> - Performs I/O against OSTs individually to allow
  55             performance comparisons to detect if an OST is performing sub-optimally due to hardware
  56             issues.</para>
  57         </listitem>
  58       </itemizedlist>
  59       <para>Typically with these tests, a Lustre file system should deliver 85-90% of the raw device
  60         performance.</para>
  61       <para>A utility <literal>stats-collect</literal> is also provided to collect application profiling information from Lustre clients and servers. See <xref linkend="dbdoclet.50438212_58201"/> for more information.</para>
  62     </section>
  63     <section remap="h3">
  64       <title>Preparing to Use the Lustre I/O Kit</title>
  65       <para>The following prerequisites must be met to use the tests in the Lustre I/O kit:</para>
  66       <itemizedlist>
  67         <listitem>
  68           <para>Password-free remote access to nodes in the system (provided by <literal>ssh</literal> or <literal>rsh</literal>).</para>
  69         </listitem>
  70         <listitem>
  71           <para>LNet self-test completed to test that Lustre networking has been properly installed
  72             and configured. See <xref linkend="lnetselftest"/>.</para>
  73         </listitem>
  74         <listitem>
  75           <para>Lustre file system software installed.</para>
  76         </listitem>
  77         <listitem>
  78           <para><literal>sg3_utils</literal>  package providing the <literal>sgp_dd</literal> tool (<literal>sg3_utils</literal> is a separate RPM package available online using YUM).</para>
  79         </listitem>
  80       </itemizedlist>
  81       <para>Download the Lustre I/O kit (<literal>lustre-iokit</literal>)from:</para>
  82       <para><link xl:href="http://downloads.whamcloud.com/">http://downloads.whamcloud.com/</link></para>
  83     </section>
  84   </section>
  85   <section xml:id="dbdoclet.50438212_51053">
  86     <title><indexterm>
  87         <primary>benchmarking</primary>
  88         <secondary>raw hardware with sgpdd-survey</secondary>
  89       </indexterm>Testing I/O Performance of Raw Hardware (<literal>sgpdd-survey</literal>)</title>
  90     <para>The <literal>sgpdd-survey</literal> tool is used to test bare metal I/O performance of the
  91       raw hardware, while bypassing as much of the kernel as possible. This survey may be used to
  92       characterize the performance of a SCSI device by simulating an OST serving multiple stripe
  93       files. The data gathered by this survey can help set expectations for the performance of a
  94       Lustre OST using this device.</para>
  95     <para>The script uses <literal>sgp_dd</literal> to carry out raw sequential disk I/O. It runs with variable numbers of <literal>sgp_dd</literal> threads to show how performance varies with different request queue depths.</para>
  96     <para>The script spawns variable numbers of <literal>sgp_dd</literal> instances, each reading or writing a separate area of the disk to demonstrate performance variance within a number of concurrent stripe files.</para>
  97     <para>Several tips and insights for disk performance measurement are described below. Some of this information is specific to RAID arrays and/or the Linux RAID implementation.</para>
  98     <itemizedlist>
  99       <listitem>
 100         <para><emphasis>Performance is limited by the slowest disk.</emphasis></para>
 101         <para>Before creating a RAID array, benchmark all disks individually. We have frequently encountered situations where drive performance was not consistent for all devices in the array. Replace any disks that are significantly slower than the rest.</para>
 102       </listitem>
 103       <listitem>
 104         <para><emphasis>Disks and arrays are very sensitive to request size.</emphasis></para>
 105         <para>To identify the optimal request size for a given disk, benchmark the disk with different record sizes ranging from 4 KB to 1 to 2 MB.</para>
 106       </listitem>
 107     </itemizedlist>
 108     <caution>
 109       <para>The <literal>sgpdd-survey</literal> script overwrites the device being tested, which
 110         results in the <emphasis>
 111           <emphasis role="bold">LOSS OF ALL DATA</emphasis>
 112         </emphasis> on that device. Exercise caution when selecting the device to be tested.</para>
 113     </caution>
 114     <note>
 115       <para>Array performance with all LUNs loaded does not always match the performance of a single LUN when tested in isolation.</para>
 116     </note>
 117     <para><emphasis role="bold">Prerequisites:</emphasis></para>
 118     <itemizedlist>
 119       <listitem>
 120         <para><literal>sgp_dd</literal>  tool in the <literal>sg3_utils</literal> package</para>
 121       </listitem>
 122       <listitem>
 123         <para>Lustre software is <emphasis>NOT</emphasis> required</para>
 124       </listitem>
 125     </itemizedlist>
 126     <para>The device(s) being tested must meet one of these two requirements:</para>
 127     <itemizedlist>
 128       <listitem>
 129         <para>If the device is a SCSI device, it must appear in the output of <literal>sg_map</literal> (make sure the kernel module <literal>sg</literal> is loaded).</para>
 130       </listitem>
 131       <listitem>
 132         <para>If the device is a raw device, it must appear in the output of <literal>raw -qa</literal>.</para>
 133       </listitem>
 134     </itemizedlist>
 135     <para>Raw and SCSI devices cannot be mixed in the test specification.</para>
 136     <note>
 137       <para>If you need to create raw devices to use the <literal>sgpdd-survey</literal> tool, note
 138         that raw device 0 cannot be used due to a bug in certain versions of the &quot;raw&quot;
 139         utility (including the version shipped with Red Hat Enterprise Linux 4U4.)</para>
 140     </note>
 141     <section remap="h3">
 142       <title><indexterm><primary>benchmarking</primary><secondary>tuning storage</secondary></indexterm>Tuning Linux Storage Devices</title>
 143       <para>To get large I/O transfers (1 MB) to disk, it may be necessary to tune several kernel parameters as specified:</para>
 144       <screen>/sys/block/sdN/queue/max_sectors_kb = 4096
 145 /sys/block/sdN/queue/max_phys_segments = 256
 146 /proc/scsi/sg/allow_dio = 1
 147 /sys/module/ib_srp/parameters/srp_sg_tablesize = 255
 148 /sys/block/sdN/queue/scheduler</screen>
 149       <note>
 150         <para>Recommended schedulers are <emphasis role="bold">deadline</emphasis> and <emphasis
 151             role="bold">noop</emphasis>. The  scheduler is set by default to <emphasis role="bold"
 152             >deadline</emphasis>, unless it has already been set to <emphasis role="bold"
 153             >noop</emphasis>.</para>
 154       </note>
 155     </section>
 156     <section remap="h3">
 157       <title>Running sgpdd-survey</title>
 158       <para>The <literal>sgpdd-survey</literal> script must be customized for the particular device
 159         being tested and for the location where the script saves its working and result files (by
 160         specifying the <literal>${rslt}</literal> variable). Customization variables are described
 161         at the beginning of the script.</para>
 162       <para>When the <literal>sgpdd-survey</literal> script runs, it creates a number of working
 163         files and a pair of result files. The names of all the files created start with the prefix
 164         defined in the variable <literal>${rslt}</literal>. (The default value is
 165           <literal>/tmp</literal>.) The files include:</para>
 166       <itemizedlist>
 167         <listitem>
 168           <para>File containing standard output data (same as <literal>stdout</literal>)</para>
 169           <screen><replaceable>rslt_date_time</replaceable>.summary</screen>
 170         </listitem>
 171         <listitem>
 172           <para>Temporary (tmp) files</para>
 173           <screen><replaceable>rslt_date_time</replaceable>_*
 174 </screen>
 175         </listitem>
 176         <listitem>
 177           <para>Collected tmp files for post-mortem</para>
 178           <screen><replaceable>rslt_date_time</replaceable>.detail
 179 </screen>
 180         </listitem>
 181       </itemizedlist>
 182       <para>The <literal>stdout</literal> and the <literal>.summary</literal> file will contain lines like this:</para>
 183       <screen>total_size 8388608K rsz 1024 thr 1 crg 1 180.45 MB/s 1 x 180.50 \
 184         = 180.50 MB/s
 185 </screen>
 186       <para>Each line corresponds to a run of the test. Each test run will have a different number of threads, record size, or number of regions.</para>
 187       <itemizedlist>
 188         <listitem>
 189           <para><literal>total_size</literal>  - Size of file being tested in KBs (8 GB in above example).</para>
 190         </listitem>
 191         <listitem>
 192           <para><literal>rsz</literal>  - Record size in KBs (1 MB in above example).</para>
 193         </listitem>
 194         <listitem>
 195           <para><literal>thr</literal>  - Number of threads generating I/O (1 thread in above example).</para>
 196         </listitem>
 197         <listitem>
 198           <para><literal>crg</literal> - Current regions, the number of disjoint areas on the disk to which I/O is being sent (1 region in above example, indicating that no seeking is done).</para>
 199         </listitem>
 200         <listitem>
 201           <para><literal>MB/s</literal>  - Aggregate bandwidth measured by dividing the total amount of data by the elapsed time (180.45 MB/s in the above example).</para>
 202         </listitem>
 203         <listitem>
 204           <para><literal>MB/s</literal>  - The remaining numbers show the number of regions X performance of the slowest disk as a sanity check on the aggregate bandwidth.</para>
 205         </listitem>
 206       </itemizedlist>
 207       <para>If there are so many threads that the <literal>sgp_dd</literal> script is unlikely to be able to allocate I/O buffers, then <literal>ENOMEM</literal> is printed in place of the aggregate bandwidth result.</para>
 208       <para>If one or more <literal>sgp_dd</literal> instances do not successfully report a bandwidth number, then <literal>FAILED</literal> is printed in place of the aggregate bandwidth result.</para>
 209     </section>
 210   </section>
 211   <section xml:id="dbdoclet.50438212_26516">
 212     <title><indexterm>
 213         <primary>benchmarking</primary>
 214         <secondary>OST performance</secondary>
 215       </indexterm>Testing OST Performance (<literal>obdfilter-survey</literal>)</title>
 216     <para>The <literal>obdfilter-survey</literal> script generates sequential I/O from varying
 217       numbers of threads and objects (files) to simulate the I/O patterns of a Lustre client.</para>
 218     <para>The <literal>obdfilter-survey</literal> script can be run directly on the OSS node to
 219       measure the OST storage performance without any intervening network, or it can be run remotely
 220       on a Lustre client to measure the OST performance including network overhead.</para>
 221     <para>The <literal>obdfilter-survey</literal> is used to characterize the performance of the
 222       following:</para>
 223     <itemizedlist>
 224       <listitem>
 225         <para><emphasis role="bold">Local file system</emphasis> - In this mode, the
 226             <literal>obdfilter-survey</literal> script exercises one or more instances of the
 227           obdfilter directly. The script may run on one or more OSS nodes, for example, when the
 228           OSSs are all attached to the same multi-ported disk subsystem.</para>
 229         <para>Run the script using the <literal>case=disk</literal> parameter to run the test against all the local OSTs. The script automatically detects all local OSTs and includes them in the survey.</para>
 230         <para>To run the test against only specific OSTs, run the script using the <literal>targets=parameter</literal> to list the OSTs to be tested explicitly. If some OSTs are on remote nodes, specify their hostnames in addition to the OST name (for example, <literal>oss2:lustre-OST0004</literal>).</para>
 231         <para>All <literal>obdfilter</literal> instances are driven directly. The script automatically loads the <literal>obdecho</literal> module (if required) and creates one instance of <literal>echo_client</literal> for each <literal>obdfilter</literal> instance in order to generate I/O requests directly to the OST.</para>
 232         <para>For more details, see <xref linkend="dbdoclet.50438212_59319"/>.</para>
 233       </listitem>
 234       <listitem>
 235         <para><emphasis role="bold">Network</emphasis>  - In this mode, the Lustre client generates I/O requests over the network but these requests are not sent to the OST file system. The OSS node runs the obdecho server to receive the requests but discards them before they are sent to the disk.</para>
 236         <para>Pass the parameters <literal>case=network</literal> and <literal>targets=<replaceable>hostname|IP_of_server</replaceable></literal> to the script. For each network case, the script does the required setup.</para>
 237         <para>For more details, see <xref linkend="dbdoclet.50438212_36037"/></para>
 238       </listitem>
 239       <listitem>
 240         <para><emphasis role="bold">Remote file system over the network</emphasis> - In this mode
 241           the <literal>obdfilter-survey</literal> script generates I/O from a Lustre client to a
 242           remote OSS to write the data to the file system.</para>
 243         <para>To run the test against all the local OSCs, pass the parameter <literal>case=netdisk</literal> to the script. Alternately you can pass the target= parameter with one or more OSC devices (e.g., <literal>lustre-OST0000-osc-ffff88007754bc00</literal>) against which the tests are to be run.</para>
 244         <para>For more details, see <xref linkend="dbdoclet.50438212_62662"/>.</para>
 245       </listitem>
 246     </itemizedlist>
 247     <caution>
 248       <para>The <literal>obdfilter-survey</literal> script is potentially destructive and there is a
 249         small risk data may be lost. To reduce this risk, <literal>obdfilter-survey</literal> should
 250         not be run on devices that contain data that needs to be preserved. Thus, the best time to
 251         run <literal>obdfilter-survey</literal> is before the Lustre file system is put into
 252         production. The reason <literal>obdfilter-survey</literal> may be safe to run on a
 253         production file system is because it creates objects with object sequence 2. Normal file
 254         system objects are typically created with object sequence 0.</para>
 255     </caution>
 256     <note>
 257       <para>If the <literal>obdfilter-survey</literal> test is terminated before it completes, some
 258         small amount of space is leaked. you can either ignore it or reformat the file
 259         system.</para>
 260     </note>
 261     <note>
 262       <para>The <literal>obdfilter-survey</literal> script is <emphasis>NOT</emphasis> scalable
 263         beyond tens of OSTs since it is only intended to measure the I/O performance of individual
 264         storage subsystems, not the scalability of the entire system.</para>
 265     </note>
 266     <note>
 267       <para>The <literal>obdfilter-survey</literal> script must be customized, depending on the
 268         components under test and where the script&apos;s working files should be kept.
 269         Customization variables are described at the beginning of the
 270           <literal>obdfilter-survey</literal> script. In particular, pay attention to the listed
 271         maximum values listed for each parameter in the script.</para>
 272     </note>
 273     <section xml:id="dbdoclet.50438212_59319">
 274       <title><indexterm><primary>benchmarking</primary><secondary>local disk</secondary></indexterm>Testing Local Disk Performance</title>
 275       <para>The <literal>obdfilter-survey</literal> script can be run automatically or manually
 276         against a local disk. This script profiles the overall throughput of storage hardware,
 277         including the file system and RAID layers managing the storage, by sending workloads to the
 278         OSTs that vary in thread count, object count, and I/O size.</para>
 279       <para>When the <literal>obdfilter-survey</literal> script is run, it provides information
 280         about the performance abilities of the storage hardware and shows the saturation
 281         points.</para>
 282       <para>The <literal>plot-obdfilter</literal> script generates from the output of the
 283           <literal>obdfilter-survey</literal> a CSV file and parameters for importing into a
 284         spreadsheet or gnuplot to visualize the data.</para>
 285       <para>To run the <literal>obdfilter-survey</literal> script, create a standard Lustre file
 286         system configuration; no special setup is needed.</para>
 287       <para><emphasis role="bold">To perform an automatic run:</emphasis></para>
 288       <orderedlist>
 289         <listitem>
 290           <para>Start the Lustre OSTs.</para>
 291           <para>The Lustre OSTs should be mounted on the OSS node(s) to be tested. The Lustre client is not required to be mounted at this time.</para>
 292         </listitem>
 293         <listitem>
 294           <para>Verify that the obdecho module is loaded. Run:</para>
 295           <screen>modprobe obdecho</screen>
 296         </listitem>
 297         <listitem>
 298           <para>Run the <literal>obdfilter-survey</literal> script with the parameter
 299               <literal>case=disk</literal>.</para>
 300           <para>For example, to run a local test with up to two objects (nobjhi), up to two threads (thrhi), and 1024 MB transfer size (size):</para>
 301           <screen>$ nobjhi=2 thrhi=2 size=1024 case=disk sh obdfilter-survey</screen>
 302         </listitem>
 303         <listitem>
 304                 <para>Performance measurements for write, rewrite, read etc are provided below:</para>
 305                 <screen># example output
 306 Fri Sep 25 11:14:03 EDT 2015 Obdfilter-survey for case=disk from hds1fnb6123
 307 ost 10 sz 167772160K rsz 1024K obj   10 thr   10 write 10982.73 [ 601.97,2912.91] rewrite 15696.54 [1160.92,3450.85] read 12358.60 [ 938.96,2634.87]
 308 ...</screen>
 309                 <para>The file <literal>./lustre-iokit/obdfilter-survey/README.obdfilter-survey</literal>
 310                 provides an explaination for the output as follows:</para>
 311                 <screen>ost 10          is the total number of OSTs under test.
 312 sz 167772160K   is the total amount of data read or written (in bytes).
 313 rsz 1024K       is the record size (size of each echo_client I/O, in bytes).
 314 obj    10       is the total number of objects over all OSTs
 315 thr    10       is the total number of threads over all OSTs and objects
 316 write           is the test name.  If more tests have been specified they
 317            all appear on the same line.
 318 10982.73        is the aggregate bandwidth over all OSTs measured by
 319            dividing the total number of MB by the elapsed time.
 320 [601.97,2912.91] are the minimum and maximum instantaneous bandwidths seen on
 321            any individual OST.
 322 Note that although the numbers of threads and objects are specifed per-OST
 323 in the customization section of the script, results are reported aggregated
 324 over all OSTs.</screen>
 325         </listitem>
 326       </orderedlist>
 327       <para><emphasis role="italic">To perform a manual run:</emphasis></para>
 328       <orderedlist>
 329         <listitem>
 330           <para>Start the Lustre OSTs.</para>
 331           <para>The Lustre OSTs should be mounted on the OSS node(s) to be tested. The Lustre client is not required to be mounted at this time.</para>
 332         </listitem>
 333         <listitem>
 334           <para>Verify that the <literal>obdecho</literal> module is loaded. Run:</para>
 335           <screen>modprobe obdecho</screen>
 336         </listitem>
 337         <listitem>
 338           <para>Determine the OST names.</para>
 339           <para>On the OSS nodes to be tested, run the <literal>lctl dl</literal> command. The OST device names are listed in the fourth column of the output. For example:</para>
 340           <screen>$ lctl dl |grep obdfilter
 341 0 UP obdfilter lustre-OST0001 lustre-OST0001_UUID 1159
 342 2 UP obdfilter lustre-OST0002 lustre-OST0002_UUID 1159
 343 ...</screen>
 344         </listitem>
 345         <listitem>
 346           <para>List all OSTs you want to test.</para>
 347           <para>Use the <literal>targets=parameter</literal> to list the OSTs separated by spaces. List the individual OSTs by name using the format
 348               <literal><replaceable>fsname</replaceable>-<replaceable>OSTnumber</replaceable></literal>
 349             (for example, <literal>lustre-OST0001</literal>). You do not have to specify an MDS or LOV.</para>
 350         </listitem>
 351         <listitem>
 352           <para>Run the <literal>obdfilter-survey</literal> script with the
 353               <literal>targets=parameter</literal>.</para>
 354           <para>For example, to run a local test with up to two objects (<literal>nobjhi</literal>), up to two threads (<literal>thrhi</literal>), and 1024 Mb (size) transfer size:</para>
 355           <screen>$ nobjhi=2 thrhi=2 size=1024 targets=&quot;lustre-OST0001 \
 356            lustre-OST0002&quot; sh obdfilter-survey</screen>
 357         </listitem>
 358       </orderedlist>
 359     </section>
 360     <section xml:id="dbdoclet.50438212_36037">
 361       <title><indexterm><primary>benchmarking</primary><secondary>network</secondary></indexterm>Testing Network Performance</title>
 362       <para>The <literal>obdfilter-survey</literal> script can only be run automatically against a
 363         network; no manual test is provided.</para>
 364       <para>To run the network test, a specific Lustre file system setup is needed. Make sure that
 365         these configuration requirements have been met.</para>
 366       <para><emphasis role="bold">To perform an automatic run:</emphasis></para>
 367       <orderedlist>
 368         <listitem>
 369           <para>Start the Lustre OSTs.</para>
 370           <para>The Lustre OSTs should be mounted on the OSS node(s) to be tested. The Lustre client is not required to be mounted at this time.</para>
 371         </listitem>
 372         <listitem>
 373           <para>Verify that the <literal>obdecho</literal> module is loaded. Run:</para>
 374           <screen>modprobe obdecho</screen>
 375         </listitem>
 376         <listitem>
 377           <para>Start <literal>lctl</literal> and check the device list, which must be empty. Run:</para>
 378           <screen>lctl dl</screen>
 379         </listitem>
 380         <listitem>
 381           <para>Run the <literal>obdfilter-survey</literal> script with the parameters
 382               <literal>case=network</literal> and
 383                 <literal>targets=<replaceable>hostname|ip_of_server</replaceable></literal>. For
 384             example:</para>
 385           <screen>$ nobjhi=2 thrhi=2 size=1024 targets=&quot;oss0 oss1&quot; \
 386            case=network sh obdfilter-survey</screen>
 387         </listitem>
 388         <listitem>
 389           <para>On the server side, view the statistics at:</para>
 390           <screen>lctl get_param obdecho.<replaceable>echo_srv</replaceable>.stats</screen>
 391           <para>where <literal><replaceable>echo_srv</replaceable></literal>
 392             is the <literal>obdecho</literal> server created by the script.</para>
 393         </listitem>
 394       </orderedlist>
 395     </section>
 396     <section xml:id="dbdoclet.50438212_62662">
 397       <title><indexterm><primary>benchmarking</primary><secondary>remote disk</secondary></indexterm>Testing Remote Disk Performance</title>
 398       <para>The <literal>obdfilter-survey</literal> script can be run automatically or manually
 399         against a network disk. To run the network disk test, start with a standard Lustre
 400         configuration. No special setup is needed.</para>
 401       <para><emphasis role="bold">To perform an automatic run:</emphasis></para>
 402       <orderedlist>
 403         <listitem>
 404           <para>Start the Lustre OSTs.</para>
 405           <para>The Lustre OSTs should be mounted on the OSS node(s) to be tested. The Lustre client is not required to be mounted at this time.</para>
 406         </listitem>
 407         <listitem>
 408           <para>Verify that the <literal>obdecho</literal> module is loaded. Run:</para>
 409           <screen>modprobe obdecho</screen>
 410         </listitem>
 411         <listitem>
 412           <para>Run the <literal>obdfilter-survey</literal> script with the parameter
 413               <literal>case=netdisk</literal>. For example:</para>
 414           <screen>$ nobjhi=2 thrhi=2 size=1024 case=netdisk sh obdfilter-survey
 415 </screen>
 416         </listitem>
 417       </orderedlist>
 418       <para><emphasis role="bold">To perform a manual run:</emphasis></para>
 419       <orderedlist>
 420         <listitem>
 421           <para>Start the Lustre OSTs.</para>
 422           <para>The Lustre OSTs should be mounted on the OSS node(s) to be tested. The Lustre client is not required to be mounted at this time.</para>
 423         </listitem>
 424         <listitem>
 425           <para>Verify that the <literal>obdecho</literal> module is loaded. Run:</para>
 426           <para>modprobe obdecho</para>
 427         </listitem>
 428         <listitem>
 429           <para>Determine the OSC names.</para>
 430           <para>On the OSS nodes to be tested, run the <literal>lctl dl</literal> command. The OSC device names are listed in the fourth column of the output. For example:</para>
 431           <screen>$ lctl dl |grep obdfilter
 432 3 UP osc lustre-OST0000-osc-ffff88007754bc00 \
 433            54b91eab-0ea9-1516-b571-5e6df349592e 5
 434 4 UP osc lustre-OST0001-osc-ffff88007754bc00 \
 435            54b91eab-0ea9-1516-b571-5e6df349592e 5
 436 ...
 437 </screen>
 438         </listitem>
 439         <listitem>
 440           <para>List all OSCs you want to test.</para>
 441           <para>Use the <literal>targets=parameter</literal> to list the OSCs separated by spaces. List the individual OSCs by name separated by spaces using the format <literal><replaceable>fsname</replaceable>-<replaceable>OST_name</replaceable>-osc-<replaceable>instance</replaceable></literal> (for example, <literal>lustre-OST0000-osc-ffff88007754bc00</literal>). You <emphasis>do not have to specify an MDS or LOV.</emphasis></para>
 442         </listitem>
 443         <listitem>
 444           <para>Run the <literal>obdfilter-survey</literal> script with the
 445                 <literal>targets=<replaceable>osc</replaceable></literal> and
 446               <literal>case=netdisk</literal>.</para>
 447           <para>An example of a local test run with up to two objects (<literal>nobjhi</literal>), up to two threads (<literal>thrhi</literal>), and 1024 Mb (size) transfer size is shown below:</para>
 448           <screen>$ nobjhi=2 thrhi=2 size=1024 \
 449            targets=&quot;lustre-OST0000-osc-ffff88007754bc00 \
 450            lustre-OST0001-osc-ffff88007754bc00&quot; sh obdfilter-survey
 451 </screen>
 452         </listitem>
 453       </orderedlist>
 454     </section>
 455     <section remap="h3">
 456       <title>Output Files</title>
 457       <para>When the <literal>obdfilter-survey</literal> script runs, it creates a number of working
 458         files and a pair of result files. All files start with the prefix defined in the variable
 459           <literal>${rslt}</literal>.</para>
 460       <informaltable frame="all">
 461         <tgroup cols="2">
 462           <colspec colname="c1" colwidth="50*"/>
 463           <colspec colname="c2" colwidth="50*"/>
 464           <thead>
 465             <row>
 466               <entry>
 467                 <para><emphasis role="bold">File</emphasis></para>
 468               </entry>
 469               <entry>
 470                 <para><emphasis role="bold">Description</emphasis></para>
 471               </entry>
 472             </row>
 473           </thead>
 474           <tbody>
 475             <row>
 476               <entry>
 477                 <para> <literal>${rslt}.summary</literal></para>
 478               </entry>
 479               <entry>
 480                 <para> Same as stdout</para>
 481               </entry>
 482             </row>
 483             <row>
 484               <entry>
 485                 <para> <literal>${rslt}.script_*</literal></para>
 486               </entry>
 487               <entry>
 488                 <para> Per-host test script files</para>
 489               </entry>
 490             </row>
 491             <row>
 492               <entry>
 493                 <para> <literal>${rslt}.detail_tmp*</literal></para>
 494               </entry>
 495               <entry>
 496                 <para> Per-OST result files</para>
 497               </entry>
 498             </row>
 499             <row>
 500               <entry>
 501                 <para> <literal>${rslt}.detail</literal></para>
 502               </entry>
 503               <entry>
 504                 <para> Collected result files for post-mortem</para>
 505               </entry>
 506             </row>
 507           </tbody>
 508         </tgroup>
 509       </informaltable>
 510       <para>The <literal>obdfilter-survey</literal> script iterates over the given number of threads
 511         and objects performing the specified tests and checks that all test processes have completed
 512         successfully.</para>
 513       <note>
 514         <para>The <literal>obdfilter-survey</literal> script may not clean up properly if it is
 515           aborted or if it encounters an unrecoverable error. In this case, a manual cleanup may be
 516           required, possibly including killing any running instances of <literal>lctl</literal>
 517           (local or remote), removing <literal>echo_client</literal> instances created by the script
 518           and unloading <literal>obdecho</literal>.</para>
 519       </note>
 520       <section remap="h4">
 521         <title>Script Output</title>
 522         <para>The <literal>.summary</literal> file and <literal>stdout</literal> of the
 523             <literal>obdfilter-survey</literal> script contain lines like:</para>
 524         <screen>ost 8 sz 67108864K rsz 1024 obj 8 thr 8 write 613.54 [ 64.00, 82.00]
 525 </screen>
 526         <para>Where:</para>
 527         <informaltable frame="all">
 528           <tgroup cols="2">
 529             <colspec colname="c1" colwidth="50*"/>
 530             <colspec colname="c2" colwidth="50*"/>
 531             <thead>
 532               <row>
 533                 <entry>
 534                   <para><emphasis role="bold">Parameter and value</emphasis></para>
 535                 </entry>
 536                 <entry>
 537                   <para><emphasis role="bold">Description</emphasis></para>
 538                 </entry>
 539               </row>
 540             </thead>
 541             <tbody>
 542               <row>
 543                 <entry>
 544                   <para> ost 8</para>
 545                 </entry>
 546                 <entry>
 547                   <para> Total number of OSTs being tested.</para>
 548                 </entry>
 549               </row>
 550               <row>
 551                 <entry>
 552                   <para> sz 67108864K</para>
 553                 </entry>
 554                 <entry>
 555                   <para> Total amount of data read or written (in KB).</para>
 556                 </entry>
 557               </row>
 558               <row>
 559                 <entry>
 560                   <para> rsz 1024</para>
 561                 </entry>
 562                 <entry>
 563                   <para> Record size (size of each echo_client I/O, in KB).</para>
 564                 </entry>
 565               </row>
 566               <row>
 567                 <entry>
 568                   <para> obj 8</para>
 569                 </entry>
 570                 <entry>
 571                   <para> Total number of objects over all OSTs.</para>
 572                 </entry>
 573               </row>
 574               <row>
 575                 <entry>
 576                   <para> thr 8</para>
 577                 </entry>
 578                 <entry>
 579                   <para> Total number of threads over all OSTs and objects.</para>
 580                 </entry>
 581               </row>
 582               <row>
 583                 <entry>
 584                   <para> write</para>
 585                 </entry>
 586                 <entry>
 587                   <para> Test name. If more tests have been specified, they all appear on the same line.</para>
 588                 </entry>
 589               </row>
 590               <row>
 591                 <entry>
 592                   <para> 613.54</para>
 593                 </entry>
 594                 <entry>
 595                   <para> Aggregate bandwidth over all OSTs (measured by dividing the total number of MB by the elapsed time).</para>
 596                 </entry>
 597               </row>
 598               <row>
 599                 <entry>
 600                   <para> [64, 82.00]</para>
 601                 </entry>
 602                 <entry>
 603                   <para> Minimum and maximum instantaneous bandwidths on an individual OST.</para>
 604                 </entry>
 605               </row>
 606             </tbody>
 607           </tgroup>
 608         </informaltable>
 609         <note>
 610           <para>Although the numbers of threads and objects are specified per-OST in the customization section of the script, the reported results are aggregated over all OSTs.</para>
 611         </note>
 612       </section>
 613       <section remap="h4">
 614         <title>Visualizing Results</title>
 615         <para>It is useful to import the <literal>obdfilter-survey</literal>
 616         script summary data (it is fixed width) into Excel (or any graphing
 617         package) and graph the bandwidth versus the number of threads for
 618         varying numbers of concurrent regions. This shows how the OSS performs
 619         for a given number of concurrently-accessed objects (files) with varying
 620         numbers of I/Os in flight.</para>
 621         <para>It is also useful to monitor and record average disk I/O sizes
 622         during each test using the &apos;disk io size&apos; histogram in the
 623         file <literal>lctl get_param obdfilter.*.brw_stats</literal>
 624         (see <xref linkend="dbdoclet.50438271_55057"/> for details). These
 625         numbers help identify problems in the system when full-sized I/Os are
 626         not submitted to the underlying disk. This may be caused by problems in
 627         the device driver or Linux block layer.</para>
 628         <para>The <literal>plot-obdfilter</literal> script included in the I/O
 629         toolkit is an example of processing output files to a .csv format and
 630         plotting a graph using <literal>gnuplot</literal>.</para>
 631       </section>
 632     </section>
 633   </section>
 634   <section xml:id="dbdoclet.50438212_85136">
 635       <title><indexterm>
 636         <primary>benchmarking</primary>
 637         <secondary>OST I/O</secondary>
 638       </indexterm>Testing OST I/O Performance (<literal>ost-survey</literal>)</title>
 639     <para>The <literal>ost-survey</literal> tool is a shell script that uses <literal>lfs
 640         setstripe</literal> to perform I/O against a single OST. The script writes a file (currently
 641       using <literal>dd</literal>) to each OST in the Lustre file system, and compares read and
 642       write speeds. The <literal>ost-survey</literal> tool is used to detect anomalies between
 643       otherwise identical disk subsystems.</para>
 644     <note>
 645       <para>We have frequently discovered wide performance variations across all LUNs in a cluster.
 646         This may be caused by faulty disks, RAID parity reconstruction during the test, or faulty
 647         network hardware.</para>
 648     </note>
 649     <para>To run the <literal>ost-survey</literal> script, supply a file size (in KB) and the Lustre
 650       file system mount point. For example, run:</para>
 651     <screen>$ ./ost-survey.sh -s 10 /mnt/lustre
 652 </screen>
 653     <para>Typical output is:</para>
 654     <screen>
 655 Number of Active OST devices : 4
 656 Worst  Read OST indx: 2 speed: 2835.272725
 657 Best   Read OST indx: 3 speed: 2872.889668
 658 Read Average: 2852.508999 +/- 16.444792 MB/s
 659 Worst  Write OST indx: 3 speed: 17.705545
 660 Best   Write OST indx: 2 speed: 128.172576
 661 Write Average: 95.437735 +/- 45.518117 MB/s
 662 Ost#  Read(MB/s)  Write(MB/s)  Read-time  Write-time
 663 ----------------------------------------------------
 664 0     2837.440       126.918        0.035      0.788
 665 1     2864.433       108.954        0.035      0.918
 666 2     2835.273       128.173        0.035      0.780
 667 3     2872.890       17.706        0.035      5.648
 668 </screen>
 669   </section>
 670   <section xml:id="mds_survey_ref">
 671     <title><indexterm><primary>benchmarking</primary><secondary>MDS
 672 performance</secondary></indexterm>Testing MDS Performance (<literal>mds-survey</literal>)</title>
 673         <para><literal>mds-survey</literal> is available in Lustre software release 2.2 and beyond. The
 674         <literal>mds-survey</literal> script tests the local metadata performance using the
 675       echo_client to drive different layers of the MDS stack: mdd, mdt, osd (the Lustre software
 676       only supports mdd stack). It can be used with the following classes of operations:</para>
 677
 678     <itemizedlist>
 679       <listitem>
 680         <para><literal>Open-create/mkdir/create</literal></para>
 681       </listitem>
 682       <listitem>
 683         <para><literal>Lookup/getattr/setxattr</literal></para>
 684       </listitem>
 685       <listitem>
 686         <para><literal>Delete/destroy</literal></para>
 687       </listitem>
 688       <listitem>
 689         <para><literal>Unlink/rmdir</literal></para>
 690       </listitem>
 691     </itemizedlist>
 692     <para>These operations will be run by a variable number of concurrent threads and will test with the number of directories specified by the user. The run can be executed such that all threads operate in a single directory (dir_count=1) or in private/unique directory (dir_count=x thrlo=x thrhi=x).</para>
 693
 694     <para>The mdd instance is driven directly. The script automatically loads the obdecho module if required and creates instance of echo_client.</para>
 695
 696     <para>This script can also create OST objects by providing stripe_count greater than zero.</para>
 697
 698     <para><emphasis role="bold">To perform a run:</emphasis></para>
 699       <orderedlist>
 700         <listitem>
 701           <para>Start the Lustre MDT.</para>
 702           <para>The Lustre MDT should be mounted on the MDS node to be tested.</para>
 703         </listitem>
 704         <listitem>
 705           <para>Start the Lustre OSTs (optional, only required when test with OST objects)</para>
 706           <para>The Lustre OSTs should be mounted on the OSS node(s).</para>
 707         </listitem>
 708         <listitem>
 709           <para>Run the <literal>mds-survey</literal> script as explain below</para>
 710           <para>The script must be customized according to the components under test and where it should keep its working files. Customization variables are described as followed:</para>
 711           <itemizedlist>
 712             <listitem>
 713               <para><literal>thrlo</literal> - threads to start testing. skipped if less than
 714                 <literal>dir_count</literal></para>
 715             </listitem>
 716             <listitem>
 717               <para><literal>thrhi</literal> - maximum number of threads to test</para>
 718             </listitem>
 719             <listitem>
 720               <para><literal>targets</literal> - MDT instance</para>
 721             </listitem>
 722             <listitem>
 723               <para><literal>file_count</literal> - number of files per thread to test</para>
 724             </listitem>
 725             <listitem>
 726               <para><literal>dir_count</literal> - total number of directories to test. Must be less
 727               than or equal to <literal>thrhi</literal></para>
 728             </listitem>
 729             <listitem>
 730               <para><literal>stripe_count </literal>- number stripe on OST objects</para>
 731             </listitem>
 732             <listitem>
 733               <para><literal>tests_str</literal> - test operations. Must have at least "create" and
 734               "destroy"</para>
 735             </listitem>
 736             <listitem>
 737               <para><literal>start_number</literal> - base number for each thread to prevent name
 738               collisions</para>
 739             </listitem>
 740             <listitem>
 741               <para><literal>layer</literal> - MDS stack's layer to be tested</para>
 742             </listitem>
 743           </itemizedlist>
 744           <para>Run without OST objects creation:</para>
 745           <para>Setup the Lustre MDS without OST mounted. Then invoke the <literal>mds-survey</literal> script</para>
 746           <screen>$ thrhi=64 file_count=200000 sh mds-survey</screen>
 747           <para>Run with OST objects creation:</para>
 748           <para>Setup the Lustre MDS with at least one OST mounted. Then invoke the
 749             <literal>mds-survey</literal> script with <literal>stripe_count</literal>
 750           parameter</para>
 751           <screen>$ thrhi=64 file_count=200000 stripe_count=2 sh mds-survey</screen>
 752           <para>Note: a specific MDT instance can be specified using targets variable.</para>
 753           <screen>$ targets=lustre-MDT0000 thrhi=64 file_count=200000 stripe_count=2 sh mds-survey</screen>
 754         </listitem>
 755       </orderedlist>
 756     <section remap="h3">
 757       <title>Output Files</title>
 758       <para>When the <literal>mds-survey</literal> script runs, it creates a number of working files and a pair of result files. All files start with the prefix defined in the variable <literal>${rslt}</literal>.</para>
 759       <informaltable frame="all">
 760         <tgroup cols="2">
 761           <colspec colname="c1" colwidth="50*"/>
 762           <colspec colname="c2" colwidth="50*"/>
 763           <thead>
 764             <row>
 765               <entry>
 766                 <para><emphasis role="bold">File</emphasis></para>
 767               </entry>
 768               <entry>
 769                 <para><emphasis role="bold">Description</emphasis></para>
 770               </entry>
 771             </row>
 772           </thead>
 773           <tbody>
 774             <row>
 775               <entry>
 776                 <para> <literal>${rslt}.summary</literal></para>
 777               </entry>
 778               <entry>
 779                 <para> Same as stdout</para>
 780               </entry>
 781             </row>
 782             <row>
 783               <entry>
 784                 <para> <literal>${rslt}.script_*</literal></para>
 785               </entry>
 786               <entry>
 787                 <para> Per-host test script files</para>
 788               </entry>
 789             </row>
 790             <row>
 791               <entry>
 792                 <para> <literal>${rslt}.detail_tmp*</literal></para>
 793               </entry>
 794               <entry>
 795                 <para> Per-mdt result files</para>
 796               </entry>
 797             </row>
 798             <row>
 799               <entry>
 800                 <para> <literal>${rslt}.detail</literal></para>
 801               </entry>
 802               <entry>
 803                 <para> Collected result files for post-mortem</para>
 804               </entry>
 805             </row>
 806           </tbody>
 807         </tgroup>
 808       </informaltable>
 809       <para>The <literal>mds-survey</literal> script iterates over the given number of threads performing the specified tests and checks that all test processes have completed successfully.</para>
 810       <note>
 811       <para>The <literal>mds-survey</literal> script may not clean up properly if it is aborted or if it encounters an unrecoverable error. In this case, a manual cleanup may be required, possibly including killing any running instances of <literal>lctl</literal>, removing <literal>echo_client</literal> instances created by the script and unloading <literal>obdecho</literal>.</para>
 812       </note>
 813     </section>
 814       <section remap="h4">
 815         <title>Script Output</title>
 816         <para>The <literal>.summary</literal> file and <literal>stdout</literal> of the <literal>mds-survey</literal> script contain lines like:</para>
 817         <screen>mdt 1 file 100000 dir 4 thr 4 create 5652.05 [ 999.01,46940.48] destroy 5797.79 [ 0.00,52951.55] </screen>
 818         <para>Where:</para>
 819         <informaltable frame="all">
 820           <tgroup cols="2">
 821             <colspec colname="c1" colwidth="50*"/>
 822             <colspec colname="c2" colwidth="50*"/>
 823             <thead>
 824               <row>
 825                 <entry>
 826                   <para><emphasis role="bold">Parameter and value</emphasis></para>
 827                 </entry>
 828                 <entry>
 829                   <para><emphasis role="bold">Description</emphasis></para>
 830                 </entry>
 831               </row>
 832             </thead>
 833             <tbody>
 834               <row>
 835                 <entry>
 836                   <para>mdt 1</para>
 837                 </entry>
 838                 <entry>
 839                   <para>Total number of MDT under test</para>
 840                 </entry>
 841               </row>
 842               <row>
 843                 <entry>
 844                   <para>file 100000</para>
 845                 </entry>
 846                 <entry>
 847                   <para>Total number of files per thread to operate</para>
 848                 </entry>
 849               </row>
 850               <row>
 851                 <entry>
 852                   <para>dir 4</para>
 853                 </entry>
 854                 <entry>
 855                   <para>Total number of directories to operate</para>
 856                 </entry>
 857               </row>
 858               <row>
 859                 <entry>
 860                   <para>thr 4</para>
 861                 </entry>
 862                 <entry>
 863                   <para>Total number of threads operate over all directories</para>
 864                 </entry>
 865               </row>
 866               <row>
 867                 <entry>
 868                   <para>create, destroy</para>
 869                 </entry>
 870                 <entry>
 871                   <para>Tests name. More tests will be displayed on the same line.</para>
 872                 </entry>
 873               </row>
 874               <row>
 875                 <entry>
 876                   <para>565.05</para>
 877                 </entry>
 878                 <entry>
 879                   <para>Aggregate operations over MDT measured by dividing the total number of operations by the elapsed time.</para>
 880                 </entry>
 881               </row>
 882               <row>
 883                 <entry>
 884                   <para>[999.01,46940.48]</para>
 885                 </entry>
 886                 <entry>
 887                   <para>Minimum and maximum instantaneous operation seen on any individual MDT</para>
 888                 </entry>
 889               </row>
 890             </tbody>
 891           </tgroup>
 892         </informaltable>
 893         <note>
 894         <para>If script output has "ERROR", this usually means there is issue during the run such as running out of space on the MDT and/or OST. More detailed debug information is available in the ${rslt}.detail file</para>
 895       </note>
 896       </section>
 897   </section>
 898   <section xml:id="dbdoclet.50438212_58201">
 899     <title><indexterm><primary>benchmarking</primary><secondary>application profiling</secondary></indexterm>Collecting Application Profiling Information (<literal>stats-collect</literal>)</title>
 900     <para>The <literal>stats-collect</literal> utility contains the following scripts used to collect application profiling information from Lustre clients and servers:</para>
 901     <itemizedlist>
 902       <listitem>
 903         <para><literal>lstat.sh</literal>  - Script for a single node that is run on each profile node.</para>
 904       </listitem>
 905       <listitem>
 906         <para><literal>gather_stats_everywhere.sh</literal>  - Script that collect statistics.</para>
 907       </listitem>
 908       <listitem>
 909         <para><literal>config.sh</literal>  - Script that contains customized configuration descriptions.</para>
 910       </listitem>
 911     </itemizedlist>
 912     <para>The <literal>stats-collect</literal> utility requires:</para>
 913     <itemizedlist>
 914       <listitem>
 915         <para>Lustre software to be installed and set up on your cluster</para>
 916       </listitem>
 917       <listitem>
 918         <para>SSH and SCP access to these nodes without requiring a password</para>
 919       </listitem>
 920     </itemizedlist>
 921     <section remap="h3">
 922       <title>Using <literal>stats-collect</literal></title>
 923       <para>The stats-collect utility is configured by including profiling configuration variables in the config.sh script. Each configuration variable takes the following form, where 0 indicates statistics are to be collected only when the script starts and stops and <emphasis>n</emphasis> indicates the interval in seconds at which statistics are to be collected:</para>
 924       <screen><replaceable>statistic</replaceable>_INTERVAL=<replaceable>0|n</replaceable></screen>
 925       <para>Statistics that can be collected include:</para>
 926       <itemizedlist>
 927         <listitem>
 928           <para><literal>VMSTAT</literal>  - Memory and CPU usage and aggregate read/write operations</para>
 929         </listitem>
 930         <listitem>
 931           <para><literal>SERVICE</literal>  - Lustre OST and MDT RPC service statistics</para>
 932         </listitem>
 933         <listitem>
 934           <para><literal>BRW</literal> - OST bulk read/write statistics (brw_stats)</para>
 935         </listitem>
 936         <listitem>
 937           <para><literal>SDIO</literal>  - SCSI disk IO statistics (sd_iostats)</para>
 938         </listitem>
 939         <listitem>
 940           <para><literal>MBALLOC</literal>  - <literal>ldiskfs</literal> block allocation statistics</para>
 941         </listitem>
 942         <listitem>
 943           <para><literal>IO</literal>  - Lustre target operations statistics</para>
 944         </listitem>
 945         <listitem>
 946           <para><literal>JBD</literal>  - ldiskfs journal statistics</para>
 947         </listitem>
 948         <listitem>
 949           <para><literal>CLIENT</literal>  - Lustre OSC request statistics</para>
 950         </listitem>
 951       </itemizedlist>
 952       <para>To collect profile information:</para>
 953       <para>Begin collecting statistics on each node specified in the config.sh script.</para>
 954       <orderedlist>
 955         <listitem>
 956           <para>Starting the collect profile daemon on each node by entering:</para>
 957           <screen>sh gather_stats_everywhere.sh config.sh start
 958 </screen>
 959         </listitem>
 960         <listitem>
 961           <para>Run the test.</para>
 962         </listitem>
 963         <listitem>
 964           <para>Stop collecting statistics on each node, clean up the temporary file, and create a profiling tarball.</para>
 965           <para>Enter:</para>
 966           <screen>sh gather_stats_everywhere.sh config.sh stop <replaceable>log_name</replaceable>.tgz</screen>
 967           <para>When <literal><replaceable>log_name</replaceable>.tgz</literal>
 968             is specified, a profile tarball <literal><replaceable>/tmp/log_name</replaceable>.tgz</literal> is created.</para>
 969         </listitem>
 970         <listitem>
 971           <para>Analyze the collected statistics and create a csv tarball for the specified profiling data.</para>
 972           <screen>sh gather_stats_everywhere.sh config.sh analyse log_tarball.tgz csv
 973 </screen>
 974         </listitem>
 975       </orderedlist>
 976     </section>
 977   </section>
 978 </chapter>