Re: Question on XIV and AS/400 -- MIDRANGE-L

Since this is all reasonably new, I would place a call to IBM Rochester and get the performance team on it. I do remember some best practices items for XIV that our friends in Rochester came up with. It sounds to me like a configuration issue on the XIV. Rochester will get the correct technicians working on it.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 7/5/2012 7:05 PM, Evan Harris wrote:

Based on that response I think you might want to get a different
external specialist.

The fact that the response has got worse as you added stuff to the XIV
kinda indicates to me that the problem is with the XIV (but I know
squat about XIV )

On Fri, Jul 6, 2012 at 8:15 AM, Kanter Mauri<itzuviem@xxxxxxx> wrote:

> I apologize for the delay in posting an answer ... A Sev1 problem on
> another plattform distracted me from this ...
>
> I will look at the monitors WRK* you mentioned...
>
> My understanding is that when we installed the new AS/400, it was the
> first which migrated onto an also new and just installed XIV and the
> response was great, but after loading the XIV with more and more stuff
> (other workloads on non AS/400 LUNs) the response time became larger ...
> My storage admin mentioned about 30 ms at high utilization ...It seems
> that the larger response time did not impact to other applications (For
> example, Win and Linuxes doing other stuff without online users and/or
> not belonging to the critical path) but impacted the AS/400 ... I
> understood from an external specialist hired to help us on this that
> part of the reason is the way the AS/400 application was coded which
> causes the XIV to think that the access is random ... May be we need to
> rethink how we coded the AS/400 application and/or allocate the
> resources to the different XIVs (we have several new ones ...)
>
> Listers, being both a newbie and only casual user of the AS/400, I must
> mention that I appreciate your willingness to help. **** THANK YOU ****
>
> Mauri.
>
>
> Evan Harris wrote:

>> You don't actually say what leads you to believe that the disk
>> subsystems are the problem other than you are now using an XIV. I
>> would have expected 3 internal disks to be a poor performer anyway
>> which leads me to believe that the system may not previously have been
>> heavy on IO for this disk configuration (if it is correct) to be OK. I
>> realise this is just supposition but...
>>
>> A quick but crude way to check whether the disks are an issue is to
>> use the WRKDSKSTS to see how busy the disks are. Issue the command
>> then refresh the display after a few minutes - if you are up around
>> 30%/40% or more on all disks all the time then this may be the
>> bottleneck.
>>
>> Alternatively you may want to look at your CPU and memory/subsystem
>> configurations to be sure the problem is indeed with the XIV. You can
>> use WRKSYSSTS to see if the CPU is maxed out or you have heavy
>> faulting in any of your memory pools - are these configured the same
>> as the previous machine ?
>>
>> Operations navigator offers some basic monitoring tools you can use to
>> try and determine whether the problem might lie so you may want to try
>> and use these to monitor what's happening with your system. This can
>> be used to measure the IO and percent busy on your disks over a longer
>> period and in a more graphical format than the WRKDSKSSTS mentioned
>> above.
>>
>> Before you go looking at the XIV you want to be sure that disk is
>> indeed the issue - apologies if you have already done this, I just get
>> the impression from your email that you may not have.
>>
>> On Tue, Jul 3, 2012 at 7:12 PM, Mauricio Kanter<mkanter@xxxxxxxxxxxxxx> wrote:

>>> Thank you all for your questions:
>>>
>>> The LUN sizes are 34GB and there are about 30 of them. In the past I think we had 3 internal disks totaling 450 GB.
>>>
>>> My XIV storage manager mentioned me he thinks the stripe size is a VIOS definition (not an XIV one) ... Is there an easy way I can check it? I do not know the machine (VIOS was configured by an external provider).
>>>
>>> Mauri.

>>

>
> --