On 14 May 2015 at 23:09, Michael Weinrich <micxer@xxxxxxxxx> 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? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
