ADSM-L

Re: [ADSM-L] Devtype FILE on NFS performance problem

2010-03-03 23:24:59
Subject: Re: [ADSM-L] Devtype FILE on NFS performance problem
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 3 Mar 2010 22:23:36 -0600
Well THAT was dramatic! Thanks, Gary.

With DIRECTIO NO set, the write speed to NFS got a LOT faster. However,
the system also started to page memory very heavily. Watching it with
topas, migration would write to NFS nicely for about 15 seconds, and
then it would stop for 5 seconds while AIX thrashed. This cycle repeats
every 20 seconds or so. Before seting DIRECTIO NO, this system didn't
page at all. It's still a large net improvement, even with the memory
thrashing.

I'm now adjusting the number of migration processes to see what number
produces the greatest total throughput, with only a tolerable amount of
thrashing. I'm also looking into AIX memory management settings.

I'm also going to watch database I/O performance closely. I've heard it
can be slowed by DIRECTIO NO.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
               Academic Computing & Communications Center


On Tue, 2 Mar 2010, Gary Bowers wrote:

>Yep, had the same problem with iSCSI volumes.  Try turning off
>directio with the following undocumented dsmserv.opt option.
>
>directio no
>
>Gary Bowers
>Storage Architect
>Itrus Technologies
>
>On Mar 1, 2010, at 10:24 PM, Roger Deschner wrote:
>
>> We have a devtype=file stgpool that is on NAS disk, accessed via NFS,
>> and we're getting very slow performance with TSM reading or writing
>> it.
>> In a test, the Unix cp command moved data about 5 times faster than
>> TSM
>> Migration.
>>
>> I have been adjusting the number of migration processes up and down,
>> while watching network data flow numbers with topas, trying to get
>> clues. There comes a point, that processor wait time goes over 90%,
>> and
>> then it hits a wall. The maximum seems to be about 10Mbytes/sec on a
>> point-to-point network consisting of three trunked GigE connections. A
>> single Unix cp command could write about 48Mbytes/sec, to the same NFS
>> filesystem, on the same NFS server, across the same network.
>>
>> Anybody else faced this kind of issue?
>>
>> Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT 
>> edu
>>               Academic Computing & Communications Center
>

<Prev in Thread] Current Thread [Next in Thread>