All of lore.kernel.org
 help / color / mirror / Atom feed
From: <eliezer@integritech.solutions>
To: "'Elliott, Robert (Persistent Memory)'" <elliott@hpe.com>,
	"'Beierl, Mark'" <Mark.Beierl@dell.com>
Cc: 'Sitsofe Wheeler' <sitsofe@gmail.com>, 'fio' <fio@vger.kernel.org>
Subject: RE: fio on vmware esxi
Date: Fri, 26 Oct 2018 17:44:40 -0500	[thread overview]
Message-ID: <000801d46d7d$7bf23f00$73d6bd00$@integritech.solutions> (raw)
In-Reply-To: <AT5PR8401MB11690CF299A451394CCC5640ABF00@AT5PR8401MB1169.NAMPRD84.PROD.OUTLOOK.COM>

Thanks for the quick feedback Robert.  I appreciate it.

I forgot to add,  when I created a new NFS datastore in VMware ESXi 6.5 I have to NFS versions to choose from:

-NFS 3 allows the datastore to be accessed by ESX/ESXi hosts of version earlier than 6.0
-NFS 4.1 provides multipathing for servers and supports the Kerberos authentication protocol

The results FIO results I posted were from NFS v.3. so I continued testing...

I unmounted that NFS volume and remounted it as a new datastore using NFS v4.1 and I'm now showing the expected IOPS using the "posixaio" engine on NFS!  Great!

So, use "posixaio" FIO engine on NFS v 4.1;  don’t use "posixaio" engine on NFS v 3.

Eliezer 

-----Original Message-----
From: Elliott, Robert (Persistent Memory) [mailto:elliott@hpe.com] 
Sent: Friday, October 26, 2018 5:30 PM
To: 'eliezer@integritech.solutions'; 'Beierl, Mark'
Cc: 'Sitsofe Wheeler'; 'fio'
Subject: RE: fio on vmware esxi


> I run FIO with the following parameters and used the different engines I listed above:
> --randrepeat=1
> --ioengine=posixaio
> --direct=1
> --sync=1
> --name=mytest
> --filename=mytestfile.fio
>  --overwrite=1
> --iodepth=64
> --size=100MB
> --readwrite=randrw
> --rwmixread=50
> --rwmixwrite=50
>  --bs=16k
> 
...
> -ioengine=psync on a 1000 IOPS Perf storage:::     read=177 write=185 IOPS
> -ioengine=pvsync on a 1000 IOPS Perf storage:::    read=176 write=184 IOPS
> -ioengine=sync on a 1000 IOPS Perf storage:::      read=145 write=152 IOPS
> -ioengine=posixaio on a 1000 IOPS Perf storage:::  read=528 write=551 IOPS*
> 
> Based on the FIO results I posted above, I've concluded that the suitable FIO engine for Block Storage
> is "posixaio"; and for NFS it can be psync or pvsync or sync.
> If I use the FIO engine "posixaio" on VMware to test block storage, I'm seeing the expected IOPS.
> However, if I use the same FIO engine ("posixaio") to test NFS, I'm NOT seeing the expected IOPS.  I'd
> have to use either psync, or pvsync, or sync to see the IOPS I'm expecting.
>   These tests are on the same baremetal server running the version of VMWare I posted above.
> 
> Can someone please shed some light on why FIO results is skewed when "posixaio" engine is used to test
> an NFS storage?   The same goes with ioengines psync/pvsync/sync skews IOPS  results on a block
> storage device?

NFS might introduce all sorts of problems.  For the block device cases...

Synchronous engines like sync do not honor the iodepth; you need to use
jobs= to get multiple concurrent IOs.  posixaio is an  asynchronous engine, 
so it is honoring your iodepth (it spawns threads for you).

Also, if your storage devices do any sort of buffering and caching, the
tiny 100 MiB size is likely to result in lots of cache hits, distorting
the results.

---
Robert Elliott, HPE Persistent Memory





  reply	other threads:[~2018-10-27  7:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 18:24 fio on vmware esxi eliezer
2018-10-10 19:05 ` Beierl, Mark
2018-10-10 19:56   ` Eliezer Nebab
2018-10-10 19:59     ` Beierl, Mark
2018-10-11  5:34       ` Sitsofe Wheeler
2018-10-11 13:42         ` Beierl, Mark
2018-10-11 19:28           ` Eliezer Nebab
2018-10-11 19:33             ` Beierl, Mark
2018-10-12  6:13           ` Sitsofe Wheeler
2018-10-12 18:18             ` Beierl, Mark
2018-10-12 18:50               ` Eliezer Nebab
     [not found]           ` <555423228.215547.1540355274473@email.1and1.com>
2018-10-24  5:05             ` Sitsofe Wheeler
2018-10-26 14:53               ` Eliezer Nebab
2018-10-26 14:54                 ` Beierl, Mark
2018-10-26 17:10                   ` Eliezer Nebab
2018-10-26 21:59                     ` eliezer
2018-10-26 22:30                       ` Elliott, Robert (Persistent Memory)
2018-10-26 22:44                         ` eliezer [this message]
2018-10-26 22:52                         ` Beierl, Mark
2018-10-27 20:34                         ` Sitsofe Wheeler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000801d46d7d$7bf23f00$73d6bd00$@integritech.solutions' \
    --to=eliezer@integritech.solutions \
    --cc=Mark.Beierl@dell.com \
    --cc=elliott@hpe.com \
    --cc=fio@vger.kernel.org \
    --cc=sitsofe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.