Filip:
Your post opens a wide range of questions, SQL performance, IBM i hosting
IBM i performance, potential cut to VIOS from IBM i hosting, etc.
First: Are you reviewing the index suggestions in the Index advisor? I
suggest "pruning" (that's a menu option) the results before you have a look
at them. Then apply some good old human intuition to it as you look at the
index suggestions. Some make sense, others may not. Go for the longest
running index builds first.
The next thing that tipped me to hardware was your comment about how many
drives might be available. Too few and nothing will help except more
drives. We suggest at least six physical drives for the host and six
virtualized drives for each hosted partition. More is better..
Using VIOS to host IBM i is a great idea, and if it uses the SAN, better.
When you create the LUNs for the partitions (Assuming these are smaller
partitions, meaning 1.5TB or less) use smaller LUN sizes to achieve your
total storage needs. So if you need 850GB, then consider using 70GB LUNs
and create 20 of them. The SAN really does not care but it will assist IBM
i in the performance. Ten (10) 140GB would be OK to if you wish.
Be careful with VIOS and vISCSI, quite frankly in a production environment
I'm not sure I would use internal storage with VIOS. IBM i would be a much
better choice for internal storage hosting.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Filip
Drzewiecki via MIDRANGE-L
Sent: Thursday, February 28, 2019 7:55 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Filip Drzewiecki <fdrzewiecki@xxxxxxxxxxxxxxxxx>
Subject: Performance issues after moving more into SQL
Hello,
I observe more and more performance issues with our application and they
started to show up after we've introduced a lot of SQL to our system. We've
did a lot of optimization but even after that we still have some problems
and I'm trying to understand what tools I can use to see if hard drives are
out bottleneck or maybe it is CPU.
System setup (from program/database perspective) is quite complicated. We've
moved from DDS to SQL tables(most tables) and MQT (materialized query
tables, biggest tables ) but programs were not changed and most of them
still use native I/O (but we have SQL behind because of RPG Open Access and
MQT/Indexes). I understand that we may have some overhead because of this(on
CPU) but for example MQT Updates/Insert are quite slow but we use the for
Read operation because chain operation with sql behind was very slow without
MQT. Of course we use SQL triggers in this setup.
We do not have EasyTier license and from what I've read it could tell us if
we could benefit from SSD. I've also found something about SSD Analyzer
(
http://www-01.ibm.com/support/docview.wss?uid=tss1prs3780) but only for 7.1
and it look like it does not work on 7.3 (I could not see it as collection
in iNavigator
We have machine type 8286-41A (power8) with 3 LPARS which has few HDD drives
(raid 5) and StorWize 5010 with few HDD Drives. Unfortunately we do not have
VIOS and LPAR 1 (master) expose HDD to DEV LPAR and PROD LPAR. This of
course should and will be changed but to be honest I have no idea how much
performance we may get if we start use VIOS.
Now I'm totally lost which tools/commands could tell me if response time
from our HDD is weak point and this is why we have slow read/write times and
our CPU does nothing because it waits for HDD(and we should buy few SSD for
hot files). We have Performance Tool so I can use collections
services/performance monitor and then print one of available reports but
there are so many of them. I guess disk report can be used.
Do You have any advices what should I check here?
Filip
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
