From: Michael Weinrich <micxer@micxer.de>
To: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Testing write master and multiple read clients on NFS share
Date: Sun, 17 May 2015 22:55:49 +0200 [thread overview]
Message-ID: <55590055.1080005@micxer.de> (raw)
In-Reply-To: <CALjAwxgWOokmtXWtN3GvZnvNoC-FTCJX=c3xFiuH5PrB97_kBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
Thanks for the hint. I also found another mistake in limiting the reads
and writes where I only wanted to limit the writes and have the reads as
fast as possible. But in general this is a viable approach to my problem?
Am 16.05.15 um 13:46 schrieb Sitsofe Wheeler:
> On 14 May 2015 at 23:09, Michael Weinrich <micxer@micxer.de> wrote:
>> Hi,
>>
>> in my company we have some sort of database that operates on bit lists read
>> directly from the files on the hard disk. While this is ok if you have an
>> SSD in your server it gets tricky to keep performance up when using an NFS
>> share.
>>
>> While I was trying to assess different solutions I stumbled upon fio and was
>> happy to see that it can also run in client-server-mode. So I was trying to
>> emulate the following scenario:
>>
>> - 1 node that takes care of updating the bit lists in the db files,
>> nothing else
>> - 5 nodes that only read from those files and respond to queries, hopefully
>> leveraging the local filesystem or NFS client cache
>>
>> I read through the HOWTO and tried to pick the options that should simulate
>> the scenario as best as possible. This is what I came up with:
>>
>> [global]
>> ioengine=sync
>> iodepth=1
>> size=100%
>> io_size=4g
>> filesize=4g
>> blocksize=64k
>> direct=0
>> numjobs=4
>> directory=/mnt/nfs
>> filename_format=index.$filenum
>> fadvise_hint=0
>> lockfile=readwrite
>> randrepeat=1
>> nrfiles=8
>> openfiles=4
>> runtime=120
>> ramp_time=10
>> blocksize=64k
>> file_service_type=random:8
>> overwrite=1
>> fsync_on_close=1
>> random_distribution=zipf:0.6
>> norandommap
>> file_append=0
>> rate=1m
>>
>> [reader]
>> rw=randread
>>
>> [writer]
>> rw=randrw
>> rwmixwrite=80
>>
>>
>> Is this a viable approach or is this scenario not really testable with fio?
>
> I could be wrong but won't this make 4 readers and 4 writers. If
> that's not what you wanted perhaps numjobs could be moved to the
> reader entry only?
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4213 bytes --]
next prev parent reply other threads:[~2015-05-17 20:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 22:09 Testing write master and multiple read clients on NFS share Michael Weinrich
2015-05-16 11:46 ` Sitsofe Wheeler
2015-05-17 20:55 ` Michael Weinrich [this message]
2015-05-20 9:03 ` Sitsofe Wheeler
2015-05-20 11:51 ` Michael Weinrich
2015-05-22 0:06 ` danielabuggie .
2015-05-24 1:15 ` Jens Axboe
2015-05-24 20:50 ` Michael Weinrich
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=55590055.1080005@micxer.de \
--to=micxer@micxer.de \
--cc=fio@vger.kernel.org \
/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.