"100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds. "
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool can offer to ZFS. Since, this is is not sustainable, you
see here ZFS trying to balance the 2 numbers.
-r
David Bond writes:
> Hi,
>
> I was directed here after posting in CIFS discuss (as i first thought that
> it could be a CIFS problem).
>
> I posted the following in CIFS:
>
> When using iometer from windows to the file share on opensolaris
> svn101 and svn111 I get pauses every 5 seconds of around 5 seconds
> (maybe a little less) where no data is transfered, when data is
> transfered it is at a fair speed and gets around 1000-2000 iops with 1
> thread (depending on the work type). The maximum read response time is
> 200ms and the maximum write response time is 9824ms, which is very
> bad, an almost 10 seconds delay in being able to send data to the
> server.
> This has been experienced on 2 test servers, the same servers have
> also been tested with windows server 2008 and they havent shown this
> problem (the share performance was slightly lower than CIFS, but it
> was consistent, and the average access time and maximums were very
> close.
>
>
> I just noticed that if the server hasnt hit its target arc size, the
> pauses are for maybe .5 seconds, but as soon as it hits its arc
> target, the iops drop to around 50% of what it was and then there are
> the longer pauses around 4-5 seconds. and then after every pause the
> performance slows even more. So it appears it is definately server
> side.
>
> This is with 100% random io with a spread of 33% write 66% read, 2KB
> blocks. over a 50GB file, no compression, and a 5.5GB target arc
> size.
>
>
>
> Also I have just ran some tests with different IO patterns and 100
> sequencial writes produce and consistent IO of 2100IOPS, except when
> it pauses for maybe .5 seconds every 10 - 15 seconds.
>
> 100% random writes produce around 200 IOPS with a 4-6 second pause
> around every 10 seconds.
>
> 100% sequencial reads produce around 3700IOPS with no pauses, just
> random peaks in response time (only 16ms) after about 1 minute of
> running, so nothing to complain about.
>
> 100% random reads produce around 200IOPS, with no pauses.
>
> So it appears that writes cause a problem, what is causing these very
> long write delays?
>
> A network capture shows that the server doesnt respond to the write
> from the client when these pauses occur.
>
> Also, when using iometer, the initial file creation doesnt have and
> pauses in the creation, so it might only happen when modifying
> files.
>
> Any help on finding a solution to this would be really appriciated.
>
> David
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
