Stephan,

The "vmstat" shows you are not actually short of memory;  The "pi" and "po"
columns are zero, so the system is not having to do any paging, and it seems
unlike the system is slow directly because of RAM shortage.  With the ARC,
it's not unusual for vmstat to show little free memory, but the system will
give up that RAM when an application asks for it.  You can tell if this is
happening a lot by:
        echo "::arc" | mdb -k | grep throttle

If the value of "memory_throttle_count" is large, that will indicate that
apps are often asking the kernel to give up ARC memory.

Also, as you said, the "iostat" figures look idle.  You can tell more
using "iostat -xn 1", which will give service times & percent-busy
figures for the actual devices.

It could be that something about the networking involved is what is
actually slow.  You could find out if it's a local bottleneck by trying
some simple I/O tests on the server itself, maybe:
        dd if=/dev/zero of=/file/in/zpool bs=1024k
and watching what iostat shows, etc.

Another test is to try a network-only test, maybe using "ttcp" between
the server and a client.  This could tell you if it's network or storage
that's causing the slow-down.  If you don't have "ttcp", something silly
like, on a client running:
        dd if=/dev/zero bs=1024k | ssh -c blowfish server "dd of=/dev/null 
bs=1024k"

You can watch network throughput on the server using:
        dladm show-link -s -i 1

Regards,

Marion


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

Reply via email to