Blake Irvin wrote: > I think I need to clarify a bit. > > I'm wondering why arc size is staying so low, when i have 10 nfs > clients and about 75 smb clients accessing the store via resharing (on > one of the 10 linux nfs clients) of the zfs/nfs export. Or is it > normal for the arc target and arc size to match? Of note, I didn't see > these performance issues until the box had been up for about a week, > probably enough time for weekly (roughly) windows reboots and profile > syncs across multiple clients to force the arc to fill.
In any case, the ARC size is not an indicator of a memory shortfall. The next time it happens, look a the scan rate in vmstat for an indication of memory shortfall. Then proceed to debug accordingly. An excellent book on this topic is the Solaris Performance and Tools companion to Solaris Internals. > > I have read through and follow the advice on the tuning guide, but > still see Windows users with roaming profiles getting very slow > profile syncs. This makes me think that zfs isn't handling the random > i/o generated by a profile sync very well. Well, at least that's what > I'm thinking when I see an arc size of 1G, there is at least another > free gig of memory, and the clients syncing more than a gig of data > fairly often. By default, the ARC leaves 1 GByte of memory free. This may or may not be appropriate for your system, which is why there are some tuning suggestions in various places. There is also an issue with the decision to cache versus flush for writes, and the interaction with write throttles. Roch did a nice writeup on changes in this area. You may be running into this, but IMHO it shouldn't appear to be a memory shortfall. Check Roch's blog to see if the symptoms are similar. http://blogs.sun.com/roch/entry/the_new_zfs_write_throttle -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
