Open IT Experts for Enterprise

Zylk empresa de desarrollo de ecommerce

Linux commands to check your disk performance

Cesar Capillas
Cesar Capillas
Yesterday I read in, NAS or SAN, that is the question, in
fact a usual question for Alfresco Administrators:
In some part of the article, Toni says that Alfresco
recommends a disk throughput greater than 200 MB/sec
so I decided to check some linux commands for measuring disk
performance. This will impact for example in the normal work of
Alfresco indexation and search (Lucene and SOLR seacrh subsystems).
Also when importing data to Alfresco via Filesystem
Bulk Module
, CMIS/REST API custom processes, or even uploading
data via CIFS, FTP or Webdav drives. Because sometimes the throughput
results of a Bulk filesystem import are not good enough as expected,
sometimes we have to think that something is rotten in the state of
benchmark, and yes, that is the question!.
Usually this can is done with hdparam and
dd commands. Below, I do some tests with my laptop with
a quite recent SSD disk
. So the results here obtained are quite
good (take in consideration: local + SSD = fast). First one is hdparm:
cesar@erotes ~ $ sudo hdparm -tT /dev/sda

 Timing cached reads:   12326 MB in  2.00 seconds = 6165.99 MB/sec
 Timing buffered disk reads: 1426 MB in  3.00 seconds = 474.67 MB/sec
The important part is related to buffered disk reads. When we are
measuring disk performance we usually talk about non cached
(or writes). This command can be applied to IDE/SATA disks
(LVM disks or iSCSI disks). The hdparm command does not work for CIFS
or NFS. For testing NFS, CIFS you can use specific utilities or check dd. 
To check write performance, it is useful the dd
command. Here again, it is important to check caches or deactivating
them for testing. You can deactivate cache writing in a disk with the
help of hdparm command too (for example for sda local sata disk
something like sudo hdparm -W1 /dev/sda)
We can test streaming (for example 1 iteration of 1G): With write
caching on, normally activated (if not you can apply sudo hdparm -W1 /dev/sda):
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile1 bs=1G count=1 oflag=direct
1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 2,44595 s, 439 MB/s
If I deactivate write caching:
cesar@erotes ~ $ sudo hdparm -W0 /dev/sda
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
And I repeat the test:
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile2 bs=1G count=1 oflag=direct
1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 6,9191 s, 155 MB/s
We see how a similar test without caches is quite worse. We can
also test latency (for example with 1000 iterations of 512b) and
activating write-cache again:
cesar@erotes ~ $ sudo hdparm -W1 /dev/sda
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile3 bs=512 count=1000 oflag=direct
1000+0 records read
1000+0 records written
512000 bytes (512 kB) copied, 0,0392862 s, 13,0 MB/s
Deactivating write-caching again:
cesar@erotes ~ $ sudo hdparm -W0 /dev/sda

 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile4 bs=512 count=1000 oflag=direct
1000+0 registros leídos
1000+0 registros escritos
512000 bytes (512 kB) copiados, 1,63136 s, 314 kB/s
This last test hurts. Roughly speaking, this is the reason why your
TV series in HD seems faster to copy than your huge icon galleries
when you upload them to Alfresco.  
Sometimes you read, that dd needs to sync data to get
"real" measurements, so the performance is in fact a little
worse (this can be achieved with the oflag=sync and repeating the
tests). The oflag modes are better explained in the second link below.
Some of the links I used for the article:

Si te ha parecido interesante comparte este post en RRS


Leer más sobre temas relacionados

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *