× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.