I wrote:
|  I have a ZFS-based NFS server (Solaris 10 U4 on x86) where I am
| seeing a weird performance degradation as the number of simultaneous
| sequential reads increases.

 To update zfs-discuss on this: after more investigation, this seems
to be due to file-level prefetching. Turning file-level prefetching
off (following the directions of the ZFS Evil Tuning Guide) returns
NFS server performance to full network bandwidth when there are lots
of simultaneous sequential reads. Unfortunately it significantly
reduces the performance of a single sequential read (when the server is
otherwise idle).

 The problem is definitely not an issue of having too many pools or too
many LUNS; I saw the same issue with a single striped pool made from 12
whole-disk LUNs. (And the issue happens locally as well as remotely, so
it's not NFS; it's just easier to measure with an NFS client, because
you can clearly see the (maximum) aggregate data rate to all of the
sequential reads.)

| CS> (It is limited testing because it is harder to accurately measure
| CS> what aggregate data rate I'm getting and harder to run that many
| CS> simultaneous reads, as if I run too many of them the Solaris
| CS> machine locks up due to overload.)
|
| that's strange - what exactly happens when it "locks up"? Does it
| panic?

 I have to apologize; this happened during an earlier round of
tests, when the Solaris machine had too little memory for the number
of pools I had on it. According to my notes, the behavior in the
with-prefetch state is that the machine can survive but is extremely
unresponsive until the test programs finish. (I haven't retested with
file prefetching turned off.)

(Here 'locks up' means it becomes basically totally unresponsive,
although it seems to still be doing IO.)

 I am using a test program that is basically dd with some reporting; it
reads a 1 MB buffer from standard in and writes it to standard out. In
these tests, each reader's stdin is a (different) 10 GB file and their
stdout is /dev/null.

        - cks
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to