|
Based on that response I think you might want to get a differentstuff
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
larger ...(other workloads on non AS/400 LUNs) the response time became
seemsMy storage admin mentioned about 30 ms at high utilization ...It
(Forthat the larger response time did not impact to other applications
and/orexample, Win and Linuxes doing other stuff without online users
tonot 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
mustrethink 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
****mention that I appreciate your willingness to help. **** THANK YOU
been
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
OK. Iheavy on IO for this disk configuration (if it is correct) to be
canrealise 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
sameuse WRKSYSSTS to see if the CPU is maxed out or you have heavy
faulting in any of your memory pools - are these configured the
toas the previous machine ?
Operations navigator offers some basic monitoring tools you can use
trytry and determine whether the problem might lie so you may want to
canand use these to monitor what's happening with your system. This
longerbe used to measure the IO and percent busy on your disks over a
getperiod 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
Kanter<mkanter@xxxxxxxxxxxxxx> wrote:the impression from your email that you may not have.
On Tue, Jul 3, 2012 at 7:12 PM, Mauricio
past I think we had 3 internal disks totaling 450 GB.Thank you all for your questions:
The LUN sizes are 34GB and there are about 30 of them. In the
a VIOS definition (not an XIV one) ... Is there an easy way I can check it?
My XIV storage manager mentioned me he thinks the stripe size is
--
Mauri.
--
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
