Date: Mon, 25 Feb 2019 17:41:48 +0530 From: Rajesh Kumar <rajfbsd@gmail.com> To: Enji Cooper <yaneurabeya@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Any ideal way to run FIO benchmarking for NVMEe devices in FreeBSD Message-ID: <CAAO%2BANP1EUJqJezsmUd6UXAzCUR4k2WEnanw_VnXwhrgk3fffQ@mail.gmail.com> In-Reply-To: <DEF69F8F-3CA0-448C-BA02-52A22CE8ECAB@gmail.com> References: <CAAO%2BANM34aY4g%2BFjPdt8F2sNo5e6N2dZdTDKavEJwvRbNJz=Gw@mail.gmail.com> <0E136DED-C1AD-481C-B243-C943D4F8D9C5@gmail.com> <CAAO%2BANPUF8u54Xvu4uN=nRAEXaLNtBX%2BJkYzRbb5jrZMRTZ6gA@mail.gmail.com> <DEF69F8F-3CA0-448C-BA02-52A22CE8ECAB@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Enji Cooper, Warner Losh, Alan Somers and Rebecca Cran for your Inputs. I did some test and here's my observation. 1) iogine "posixaio" (or) "sync" - no much difference. Is this expected? 2) As said, raw device gives better numbers compared to filesystem. 3) With "thread" option, I see the numbers going considerably down. Is this expected? 4) I see good numbers for IOPS, but the MB/s is less comparatively. Any reasons? Enji Cooper, the mentioned link has all the documents (data sheet, user guide etc.,). Not sure if you have seen them. Anyway, I will consider about the points you have mentioned in my testing and see how they impact the performance. Thanks. Thanks, Rajesh. On Fri, Feb 22, 2019 at 9:24 PM Enji Cooper <yaneurabeya@gmail.com> wrote: > > On Feb 22, 2019, at 01:29, Rajesh Kumar <rajfbsd@gmail.com> wrote: > > Hi Enji Cooper, > > I am using Samsung 960 PRO > > https://www.samsung.com/semiconductor/minisite/ssd/product/consumer/960pr= o/ > > > Hi Rajesh, > I asked about the datasheet, because there might be some hints in > terms of the number of parallel jobs you might want to apply as well as t= he > I/O queue depth, which will affect the performance of the drive. Otherwis= e > you=E2=80=99ll be throwing values against a wall, seeing what will stick,= which is > sort of ok if you bound your testing and adjust based on performance, but > if your initial hunch is off, it can mislead you. > Similarly, check to see if there are any tunables or sysctls that wil= l > bound the device in terms of the queue depth and I/O requests. > As others have noted, test the device directly if you want to know it= s > raw performance. Only test with a filesystem if your intent is to see how > the device will perform with a filesystem on it (and disable filesystem > sync if you want to test max throughput with the overhead of a filesystem= ). > Testing with a filesystem can reveal some potentially interesting > characteristics, in terms of limitations in VFS / the filesystem > implementation, which might be helpful if you=E2=80=99re trying to determ= ine why > there=E2=80=99s a difference between raw device speed and the speed with = a > filesystem on it. Testing with the same file in different directories is > ok, as long as you blow the drive cache=E2=80=94which will have a noticea= ble > performance impact on conventional (PMR, SMR, etc) drives, as you want to > test the worst case speed of the device, instead of the cache. It should > matter a bit less with faster devices like SSDs/NVMe drives. Testing with > files in the same lateral filesystem hierarchy (same directory), might > reveal issues with filesystem locking (directory inode performance), but > that shouldn=E2=80=99t be the primary goal of your testing. It=E2=80=99s = just something to > keep in mind. > Happy testing! > HTH, > -Enji >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAO%2BANP1EUJqJezsmUd6UXAzCUR4k2WEnanw_VnXwhrgk3fffQ>