Discussion:
Disk: Percent full a performance factor?
(too old to reply)
r***@public.gmane.org
2014-10-20 18:29:10 UTC
Permalink
Raw Message
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Alan Shore
2014-10-20 18:32:04 UTC
Permalink
Raw Message
We have gone as high as 94% on our dev box before we saw things happening (or not happening - depending on what you were looking at)


Alan Shore
E-mail : ASHORE-***@public.gmane.org
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really didn't want to go over 80% of disk space used. I had a manager (came from the programmer pit and rose through the ranks) that wondered if that still held true with the growth of disk. After all, 20% free of a whole gig of disk space sure was a lot more than 20% of 300MB. I argued that object size was significantly larger and that reorgs and whatnot still needed significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 18:59:31 UTC
Permalink
Raw Message
I am aware of things like

System value . . . . . : QSTGLOWLMT
Description . . . . . : Auxiliary storage lower limit
Lower limit . . . . . : 5.0000 0-100 percent

STRSST
3. Work with disk units
2. Work with disk configuration
3. Work with ASP threshold
----Protected--- ---Unprotected--
ASP Threshold Overflow Size %Used Size %Used
1 90% No 0 0.00% 1565917 72.29%

And how they affect things like smtp and whatnot. I was talking about
things outside of these two controls.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Alan Shore <ashore-lHKq/***@public.gmane.org>
To: Midrange Systems Technical Discussion <midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 02:39 PM
Subject: RE: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



We have gone as high as 94% on our dev box before we saw things happening
(or not happening - depending on what you were looking at)


Alan Shore
E-mail : ASHORE-***@public.gmane.org
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Vincent Forbes
2014-10-20 19:14:38 UTC
Permalink
Raw Message
I had a system with 1.5T disk and was at 55%. A runaway job took it to 98% in 1/2 hour while I was in transit to work. I was just able to end it in time.

I changed that job to have limits & error checking. But if I was running at 80%...

Vincent Forbes
Post by Alan Shore
We have gone as high as 94% on our dev box before we saw things happening (or not happening - depending on what you were looking at)
Alan Shore
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
Sent: Monday, October 20, 2014 2:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really didn't want to go over 80% of disk space used. I had a manager (came from the programmer pit and rose through the ranks) that wondered if that still held true with the growth of disk. After all, 20% free of a whole gig of disk space sure was a lot more than 20% of 300MB. I argued that object size was significantly larger and that reorgs and whatnot still needed significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:22:04 UTC
Permalink
Raw Message
Yeah, there are so many people that want you to remove limits. Like
'Hey my job ended because the job message queue got full.'
'Why did the job message queue get full?'
'Because this job got into a loop.'
'So, was the problem that the job message queue got full, or, that the job
got into a loop that filled up the job message queue?'
'oh....'

Granted, there are times when you have to set your job message queue to
infinite. Like applying certain ptf cumes and whatnot.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Vincent Forbes" <vforbes-***@public.gmane.org>
To: Midrange Systems Technical Discussion <midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 03:14 PM
Subject: RE: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



I had a system with 1.5T disk and was at 55%. A runaway job took it to 98%
in 1/2 hour while I was in transit to work. I was just able to end it in
time.

I changed that job to have limits & error checking. But if I was running
at 80%...

Vincent Forbes
Post by Alan Shore
We have gone as high as 94% on our dev box before we saw things
happening (or not happening - depending on what you were looking at)
Post by Alan Shore
Alan Shore
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
Sent: Monday, October 20, 2014 2:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Post by Alan Shore
Now that we're measuring disk in TB and MB is nought but a rounding
error does 80% still hold true? If so, why?
Post by Alan Shore
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Post by Alan Shore
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Sue Baker
2014-10-20 18:53:36 UTC
Permalink
Raw Message
Post by r***@public.gmane.org
Now that we're measuring disk in TB and MB is nought but a
rounding error does 80% still hold true? If so, why?
The reason for the recommendation is based on HDD performance
characteristics. Rotational delay and seek distance add
latencies when trying to move from track to track on the
platters.

It can be argued this does not hold true for SSDs due to no
latency to move from "track to track" as there are no tracks and
nothing spins! But 100% SSD configurations are still the rarity
rather than the norm so changing the guideline likely won't
happen until 100% HDD configurations become a rarity.

I believe you need to consider your workload's unique
characteristics for creating new stuff, enlarging existing
stuff, and deleting stuff regardless of whether you are 100%
HDD, 100% SSD, or some combination of the two. Trying to find
extents or logical block addresses when creating and extending
can create performance issues when over 80-85% full. Then you
add the latency from HDDs and you see where the guidance comes
from.

As an aside .... I have one customer who has an LPAR which can
run at 94-96% full without any performance penalty. We
benchmarked with a range of %full from 70 to 95% and 95% ran as
effectively as 70%. Another LPAR for the same customer suffers
horribly as soon as the 83.5% mark is crossed. Again, tested
and validated.

File size for critical files which may require a 2nd copy on
disk for some reason is also important to consider. What if you
decide to increase %full to 90% but a copy of your largest file
won't fit in the remaining GBs and it is critical to make a copy
for some reason? There are many ways to slice and dice this
"what if" question. What makes sense for your business may be
very different than what makes sense for someone else.
--
Sue
IBM Americas Advanced Technical Sales Support (ATS) Power
Systems
Rochester, MN
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:14:32 UTC
Permalink
Raw Message
Thank you for that detailed answer.

Yes, we used to have a system that we used to save/restore one file
because the disk didn't have enough space to do a reorg of it.
Some vendor supplied EDI history file.
Had to reorg on another system.
But that was many years ago.

I appreciate the information on extents and stuff. Tempered with the wide
variety of performance difference you are seeing with just that one
customer on different lpars.



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Sue Baker <sue.baker-r/Jw6+rmf7HQT0dZR+***@public.gmane.org>
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Date: 10/20/2014 02:53 PM
Subject: Re: Disk: Percent full a performance factor?
Post by r***@public.gmane.org
Now that we're measuring disk in TB and MB is nought but a
rounding error does 80% still hold true? If so, why?
The reason for the recommendation is based on HDD performance
characteristics. Rotational delay and seek distance add
latencies when trying to move from track to track on the
platters.

It can be argued this does not hold true for SSDs due to no
latency to move from "track to track" as there are no tracks and
nothing spins! But 100% SSD configurations are still the rarity
rather than the norm so changing the guideline likely won't
happen until 100% HDD configurations become a rarity.

I believe you need to consider your workload's unique
characteristics for creating new stuff, enlarging existing
stuff, and deleting stuff regardless of whether you are 100%
HDD, 100% SSD, or some combination of the two. Trying to find
extents or logical block addresses when creating and extending
can create performance issues when over 80-85% full. Then you
add the latency from HDDs and you see where the guidance comes
from.

As an aside .... I have one customer who has an LPAR which can
run at 94-96% full without any performance penalty. We
benchmarked with a range of %full from 70 to 95% and 95% ran as
effectively as 70%. Another LPAR for the same customer suffers
horribly as soon as the 83.5% mark is crossed. Again, tested
and validated.

File size for critical files which may require a 2nd copy on
disk for some reason is also important to consider. What if you
decide to increase %full to 90% but a copy of your largest file
won't fit in the remaining GBs and it is critical to make a copy
for some reason? There are many ways to slice and dice this
"what if" question. What makes sense for your business may be
very different than what makes sense for someone else.
--
Sue
IBM Americas Advanced Technical Sales Support (ATS) Power
Systems
Rochester, MN
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Oberholtzer
2014-10-20 18:53:52 UTC
Permalink
Raw Message
Rob,

It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.

Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 1:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:16:11 UTC
Permalink
Raw Message
Thank you.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 02:54 PM
Subject: RE: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Rob,

It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.

Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD
device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 1:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe,
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
DrFranken
2014-10-20 19:48:48 UTC
Permalink
Raw Message
Yes BUT. Fragmentation will begin to create issues.

The reason % busy can climb when disks fill is that instead of just
driving the car into the garage you must first remove the wheels the
front and rear bumpers and put them into the garage. Then lower the drop
top and tip it on it's side on a cart and slip it in the available
space. Yes the trip to work tomorrow is gonna suck too as you have to
undo this effort to drive it again.

So enough arms as Jim suggests helps with this but extra effort is still
required it's just hidden by extra capacity. If that's OK in your shop
good for you. (Really!) But if you're pushing the %busy to a point where
those extra I/Os hit knee of curve then that's bad.

It makes a HUGE difference what sort of I/O you are doing. If it's
causing the data to move about with sorting and index builds and reorgs
and restores and copies then this will matter much more to you as
fragmentation will be far worse with that activity.

On the flip side I have customers with IBM i 7.1 as a host partition
with nothing but NWSSTG filling the disk to 95%. They have been that way
for over a year and a half with no issue whatever because those things
are written to their full size when built and never move. The I/O is
just within them.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
Post by Jim Oberholtzer
Rob,
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
Sent: Monday, October 20, 2014 1:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 20:06:46 UTC
Permalink
Raw Message
<snip>
On the flip side I have customers with IBM i 7.1 as a host partition
with nothing but NWSSTG filling the disk to 95%. They have been that way
for over a year and a half with no issue whatever because those things
are written to their full size when built and never move. The I/O is
just within them.
</snip>
This sounds like our RACK#HST lpars.
They still have a lot of free space.
Many of the lpars they host are running somewhat high.

Current Current
System System % of ASP %
Name ASP Used Busy
-------- -------------- -------- ----
MAIL3 1,304,932 87.4734 0
MAILTWO 2,870,769 85.6758 0
MAIL1 2,870,769 83.5124 0
GDWEB 447,411 83.2338
GDI 596,548 77.1158
GDISYS2 1,174,438 75.3184
GDISYS 1,565,918 72.0907
GDIHQ2 5,219,580 68.2793
GDIHQ 5,480,559 65.2312 0
RACK2HST 22,500,008 64.2266
RACK1HST 23,277,381 54.3078
GDWEB2 447,411 51.3064
RACK3HST 5,956,700 45.8073
GDWEB3 447,411 39.0542
Only checked % Busy on 4 of these lpars other than the RACK#HST lpars I
reported on in an earlier email.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: DrFranken <midrange-f4GYfadWyJRWk0Htik3J/***@public.gmane.org>
To: Midrange Systems Technical Discussion <midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 03:49 PM
Subject: Re: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Yes BUT. Fragmentation will begin to create issues.

The reason % busy can climb when disks fill is that instead of just
driving the car into the garage you must first remove the wheels the
front and rear bumpers and put them into the garage. Then lower the drop
top and tip it on it's side on a cart and slip it in the available
space. Yes the trip to work tomorrow is gonna suck too as you have to
undo this effort to drive it again.

So enough arms as Jim suggests helps with this but extra effort is still
required it's just hidden by extra capacity. If that's OK in your shop
good for you. (Really!) But if you're pushing the %busy to a point where
those extra I/Os hit knee of curve then that's bad.

It makes a HUGE difference what sort of I/O you are doing. If it's
causing the data to move about with sorting and index builds and reorgs
and restores and copies then this will matter much more to you as
fragmentation will be far worse with that activity.

On the flip side I have customers with IBM i 7.1 as a host partition
with nothing but NWSSTG filling the disk to 95%. They have been that way
for over a year and a half with no issue whatever because those things
are written to their full size when built and never move. The I/O is
just within them.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
Post by Jim Oberholtzer
Rob,
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
Sent: Monday, October 20, 2014 1:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
unsubscribe,
Post by Jim Oberholtzer
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Oberholtzer
2014-10-20 20:17:11 UTC
Permalink
Raw Message
I did suggest disk busy had to be in range as well...... With the hosted
disk the disk busy on the primary (hosting) LPAR is going to be minimal. On
a box with heavy index creation, yikes......

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
DrFranken
Sent: Monday, October 20, 2014 2:49 PM
To: Midrange Systems Technical Discussion
Subject: Re: Disk: Percent full a performance factor?

Yes BUT. Fragmentation will begin to create issues.

The reason % busy can climb when disks fill is that instead of just driving
the car into the garage you must first remove the wheels the front and rear
bumpers and put them into the garage. Then lower the drop top and tip it on
it's side on a cart and slip it in the available space. Yes the trip to work
tomorrow is gonna suck too as you have to undo this effort to drive it
again.

So enough arms as Jim suggests helps with this but extra effort is still
required it's just hidden by extra capacity. If that's OK in your shop good
for you. (Really!) But if you're pushing the %busy to a point where those
extra I/Os hit knee of curve then that's bad.

It makes a HUGE difference what sort of I/O you are doing. If it's causing
the data to move about with sorting and index builds and reorgs and restores
and copies then this will matter much more to you as fragmentation will be
far worse with that activity.

On the flip side I have customers with IBM i 7.1 as a host partition with
nothing but NWSSTG filling the disk to 95%. They have been that way for over
a year and a half with no issue whatever because those things are written to
their full size when built and never move. The I/O is just within them.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
Post by Jim Oberholtzer
Rob,
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with
6 devices, you're in for a hard time.
Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then
that percent full you have to be concerned with goes up as well, so
higher percent full is OK.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
Sent: Monday, October 20, 2014 1:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you
really didn't want to go over 80% of disk space used. I had a manager
(came from the programmer pit and rose through the ranks) that
wondered if that still held true with the growth of disk. After all,
20% free of a whole gig of disk space sure was a lot more than 20% of
300MB. I argued that object size was significantly larger and that
reorgs and whatnot still needed significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding
error does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
a moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-21 11:05:05 UTC
Permalink
Raw Message
<snip>
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
</snip>

Is this so true anymore, about the number of disk arms being so critical?
I hear people speak that mantra all the time yet I've found that the newer
disks, controllers, etc have always amazed me. Many years ago we dropped
a system down from 42 disk arms down to just 7 of the then newer drives
(still spinning disks) and my performance was significantly better.

Recently I've dropped from some lpars each having dozens of their own disk
drives down to 21 storage spaces on a system with only 32 drives (and that
was only 1 of the 5 lpars being guested from this host) and the
performance was much better. Ok, granted, I went from a mix of SSD's and
HDD's to pure SSD's, of a newer generation.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 02:54 PM
Subject: RE: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Rob,

It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.

Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD
device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 1:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe,
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Midrange
2014-10-21 12:16:27 UTC
Permalink
Raw Message
Post by r***@public.gmane.org
Ok, granted, I went from a mix of SSD's and
HDD's to pure SSD's, of a newer generation.
Right. My mileage got like four times better when I started buying gasoline in 2008 from a new station. Yes I began putting it into a Prius instead of a V8 4x4 Dodge Ram at the same time but I think it was just better gas :-)

Seriously you're likely behind better cards too and with faster SAS buses maybe even in faster PCI slots. Of course all that matters, but the one thing you gotta do is get each LPAR a minimum of 6 drives real or virtual. Want to prove it to yourself, create a single 1TB NWSSTG and load everything to that and see how it runs/walks/crawls....

Larry

Sent from my iPad
Post by r***@public.gmane.org
<snip>
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
</snip>
Is this so true anymore, about the number of disk arms being so critical?
I hear people speak that mantra all the time yet I've found that the newer
disks, controllers, etc have always amazed me. Many years ago we dropped
a system down from 42 disk arms down to just 7 of the then newer drives
(still spinning disks) and my performance was significantly better.
Recently I've dropped from some lpars each having dozens of their own disk
drives down to 21 storage spaces on a system with only 32 drives (and that
was only 1 of the 5 lpars being guested from this host) and the
performance was much better. Ok, granted, I went from a mix of SSD's and
HDD's to pure SSD's, of a newer generation.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
To: "'Midrange Systems Technical Discussion'"
Date: 10/20/2014 02:54 PM
Subject: RE: Disk: Percent full a performance factor?
Rob,
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
Sent: Monday, October 20, 2014 1:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-21 12:36:40 UTC
Permalink
Raw Message
Good analogy.

And, yes, I did switch from just one storage space for each guest to a
minimum of 6 and often many more. I kind of like to keep the sizes in
each lpar all the same. I also like to keep them somewhat representative
of current market disk drives. Anywhere from 80GB to 280GB each drive. I
know you understand why I said 80 instead of 70 on the small end. Not so
big that adding another drive as they expand is a huge decision. But not
so small on the larger lpars that I get a ridiculous number of drives.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Midrange <midrange-f4GYfadWyJRWk0Htik3J/***@public.gmane.org>
To: Midrange Systems Technical Discussion <midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/21/2014 08:16 AM
Subject: Re: Disk: Percent full a performance factor?
Post by r***@public.gmane.org
Ok, granted, I went from a mix of SSD's and
HDD's to pure SSD's, of a newer generation.
Right. My mileage got like four times better when I started buying
gasoline in 2008 from a new station. Yes I began putting it into a Prius
instead of a V8 4x4 Dodge Ram at the same time but I think it was just
better gas :-)

Seriously you're likely behind better cards too and with faster SAS buses
maybe even in faster PCI slots. Of course all that matters, but the one
thing you gotta do is get each LPAR a minimum of 6 drives real or virtual.
Want to prove it to yourself, create a single 1TB NWSSTG and load
everything to that and see how it runs/walks/crawls....

Larry

Sent from my iPad
Post by r***@public.gmane.org
<snip>
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
</snip>
Is this so true anymore, about the number of disk arms being so critical?
I hear people speak that mantra all the time yet I've found that the newer
disks, controllers, etc have always amazed me. Many years ago we dropped
a system down from 42 disk arms down to just 7 of the then newer drives
(still spinning disks) and my performance was significantly better.
Recently I've dropped from some lpars each having dozens of their own disk
drives down to 21 storage spaces on a system with only 32 drives (and that
was only 1 of the 5 lpars being guested from this host) and the
performance was much better. Ok, granted, I went from a mix of SSD's and
HDD's to pure SSD's, of a newer generation.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
To: "'Midrange Systems Technical Discussion'"
Date: 10/20/2014 02:54 PM
Subject: RE: Disk: Percent full a performance factor?
Rob,
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
Sent: Monday, October 20, 2014 1:29 PM
Subject: Disk: Percent full a performance factor?
The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Oberholtzer
2014-10-21 12:33:28 UTC
Permalink
Raw Message
Yes it still counts. It's not so much the speed of the DASD or the
controller, but the queuing inside IBM i. The more drives the more queues.
In order to keep performance at acceptable levels you'll need at least 6
DASD units.

As to the folks that see massive performance improvements with fewer drives,
when you change the engine from a 1.2 liter 2 piston to a V8 4.6 liter
supercharged engine, you might just get off the line a little quicker......

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Tuesday, October 21, 2014 6:05 AM
To: Midrange Systems Technical Discussion
Subject: RE: Disk: Percent full a performance factor?

<snip>
It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.
</snip>

Is this so true anymore, about the number of disk arms being so critical?
I hear people speak that mantra all the time yet I've found that the newer
disks, controllers, etc have always amazed me. Many years ago we dropped a
system down from 42 disk arms down to just 7 of the then newer drives (still
spinning disks) and my performance was significantly better.

Recently I've dropped from some lpars each having dozens of their own disk
drives down to 21 storage spaces on a system with only 32 drives (and that
was only 1 of the 5 lpars being guested from this host) and the performance
was much better. Ok, granted, I went from a mix of SSD's and HDD's to pure
SSD's, of a newer generation.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 02:54 PM
Subject: RE: Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Rob,

It depends on how many DASD devices there are. If there are say 40-50
devices then running up to 85% -- 88% might not be a problem, but with 6
devices, you're in for a hard time.

Generally Databases tell you the knee in the response time curve starts at
about 80% and steepens quickly but with IBM i, as long as the DASD
device
busy percentages are OK and there is room for temporary indexes, then that
percent full you have to be concerned with goes up as well, so higher
percent full is OK.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 1:29 PM
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Subject: Disk: Percent full a performance factor?

The old rule of thumb I had learned back on the S/36 was that you really
didn't want to go over 80% of disk space used. I had a manager (came from
the programmer pit and rose through the ranks) that wondered if that still
held true with the growth of disk. After all, 20% free of a whole gig of
disk space sure was a lot more than 20% of 300MB. I argued that object
size
was significantly larger and that reorgs and whatnot still needed
significant portions of disk space.
Now that we're measuring disk in TB and MB is nought but a rounding error
does 80% still hold true? If so, why?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org To subscribe,
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:46:00 UTC
Permalink
Raw Message
On a loosely related note, what performance considerations should one
really watch for on an lpar that does nothing but host disk? For example
on our Power 8's all disk (except to the vios lpars) is hosted by one lpar
of IBM i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
DrFranken
2014-10-20 20:00:00 UTC
Permalink
Raw Message
Just saw this after my previous note. We've not seen it be a factor if
the host partition is truly just that. NOTHING FRIGGIN ELSE in there.
Not an FTP host not running any workload. In fact you can have the
system in restricted condition and the guest partitions roll on.

Gone to 95% full and not seen an issue.

Now Some Say that the hosted disk should all be in it's on ASP. Done
that too AND it allows PowerHA to mirror entire systems. (VERY cool by
the way) This way you can be assured that no other I/O is in those pools
and that no fragmentation is occuring as nothing whatever is moving on
those disks.

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
Post by r***@public.gmane.org
On a loosely related note, what performance considerations should one
really watch for on an lpar that does nothing but host disk? For example
on our Power 8's all disk (except to the vios lpars) is hosted by one lpar
of IBM i. This then hosts several lpars of IBM i and AIX.
RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16
RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12
RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12
Rob Berendt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Oberholtzer
2014-10-20 20:14:10 UTC
Permalink
Raw Message
Do you have the network servers using a pool identifier (I always use
*SHRPOOL50) to push the I/O memory there? That keeps it out of *BASE.

With 10TB of storage being hosted I have 4096 GB in that pool and that's
almost overkill. You might get away with 3Gb instead.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

On a loosely related note, what performance considerations should one really
watch for on an lpar that does nothing but host disk? For example on our
Power 8's all disk (except to the vios lpars) is hosted by one lpar of IBM
i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-21 10:49:24 UTC
Permalink
Raw Message
Thank you for that idea. I'll check into it.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 04:14 PM
Subject: RE: Performance considerations of a disk hosting lpar Was:
Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Do you have the network servers using a pool identifier (I always use
*SHRPOOL50) to push the I/O memory there? That keeps it out of *BASE.

With 10TB of storage being hosted I have 4096 GB in that pool and that's
almost overkill. You might get away with 3Gb instead.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

On a loosely related note, what performance considerations should one
really
watch for on an lpar that does nothing but host disk? For example on our
Power 8's all disk (except to the vios lpars) is hosted by one lpar of IBM
i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-21 10:52:12 UTC
Permalink
Raw Message
WRKNWSD
Work with Network Server Descriptions
5=Display
Pool identifier . . . . . . . . . : *BASE
System pool identifier . . . . . : 2

WRKSHRPOOL
Defined Max Allocated Pool -Paging Option--
Pool Size (M) Active Size (M) ID Defined Current
*MACHINE 947.58 +++++ 947.58 1 *FIXED *FIXED
*BASE 6278.33 145 6278.33 2 *FIXED *FIXED
*INTERACT 811.89 203 811.89 3 *FIXED *FIXED
*SPOOL 81.18 5 81.18 4 *FIXED *FIXED
*SHRPOOL1 .00 0 *FIXED
*SHRPOOL2 .00 0 *FIXED
*SHRPOOL3 .00 0 *FIXED
*SHRPOOL4 .00 0 *FIXED
*SHRPOOL5 .00 0 *FIXED



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 04:14 PM
Subject: RE: Performance considerations of a disk hosting lpar Was:
Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Do you have the network servers using a pool identifier (I always use
*SHRPOOL50) to push the I/O memory there? That keeps it out of *BASE.

With 10TB of storage being hosted I have 4096 GB in that pool and that's
almost overkill. You might get away with 3Gb instead.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

On a loosely related note, what performance considerations should one
really
watch for on an lpar that does nothing but host disk? For example on our
Power 8's all disk (except to the vios lpars) is hosted by one lpar of IBM
i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Jim Oberholtzer
2014-10-21 11:29:36 UTC
Permalink
Raw Message
Rob,

You need to get after the work management a bit. I'd start with putting the
network servers into a shared pool. You will have to vary them off and on
again which of course means shutting down your partition. If the
performance of the hosted partition is OK then it will wait until you have a
maintenance window.

Unless, you've got a situation (and guts enough) where you can vary off one
server, make the change and vary it back on again quickly. You'll get a
really nasty SRC about losing devices (disk in this case) and then when it
varies back on it will see the disk units again and happily take off again.
Give the partition time to get its collective stuff together then do the
next one. Ugly, but it'll work if you simply cannot IPL the partition.
Don't ask how I know it will work.........

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Tuesday, October 21, 2014 5:52 AM
To: Midrange Systems Technical Discussion
Subject: RE: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

WRKNWSD
Work with Network Server Descriptions
5=Display
Pool identifier . . . . . . . . . : *BASE
System pool identifier . . . . . : 2

WRKSHRPOOL
Defined Max Allocated Pool -Paging Option--
Pool Size (M) Active Size (M) ID Defined Current
*MACHINE 947.58 +++++ 947.58 1 *FIXED *FIXED
*BASE 6278.33 145 6278.33 2 *FIXED *FIXED
*INTERACT 811.89 203 811.89 3 *FIXED *FIXED
*SPOOL 81.18 5 81.18 4 *FIXED *FIXED
*SHRPOOL1 .00 0 *FIXED
*SHRPOOL2 .00 0 *FIXED
*SHRPOOL3 .00 0 *FIXED
*SHRPOOL4 .00 0 *FIXED
*SHRPOOL5 .00 0 *FIXED



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 04:14 PM
Subject: RE: Performance considerations of a disk hosting lpar Was:
Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Do you have the network servers using a pool identifier (I always use
*SHRPOOL50) to push the I/O memory there? That keeps it out of *BASE.

With 10TB of storage being hosted I have 4096 GB in that pool and that's
almost overkill. You might get away with 3Gb instead.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

On a loosely related note, what performance considerations should one
really
watch for on an lpar that does nothing but host disk? For example on our
Power 8's all disk (except to the vios lpars) is hosted by one lpar of IBM
i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-21 11:45:12 UTC
Permalink
Raw Message
Adding this to my list to do for my December maintenance window


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/21/2014 07:35 AM
Subject: RE: Performance considerations of a disk hosting lpar Was:
Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Rob,

You need to get after the work management a bit. I'd start with putting
the
network servers into a shared pool. You will have to vary them off and on
again which of course means shutting down your partition. If the
performance of the hosted partition is OK then it will wait until you have
a
maintenance window.

Unless, you've got a situation (and guts enough) where you can vary off
one
server, make the change and vary it back on again quickly. You'll get a
really nasty SRC about losing devices (disk in this case) and then when it
varies back on it will see the disk units again and happily take off
again.
Give the partition time to get its collective stuff together then do the
next one. Ugly, but it'll work if you simply cannot IPL the partition.
Don't ask how I know it will work.........

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Tuesday, October 21, 2014 5:52 AM
To: Midrange Systems Technical Discussion
Subject: RE: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

WRKNWSD
Work with Network Server Descriptions
5=Display
Pool identifier . . . . . . . . . : *BASE
System pool identifier . . . . . : 2

WRKSHRPOOL
Defined Max Allocated Pool -Paging Option--
Pool Size (M) Active Size (M) ID Defined Current
*MACHINE 947.58 +++++ 947.58 1 *FIXED *FIXED
*BASE 6278.33 145 6278.33 2 *FIXED *FIXED
*INTERACT 811.89 203 811.89 3 *FIXED *FIXED
*SPOOL 81.18 5 81.18 4 *FIXED *FIXED
*SHRPOOL1 .00 0 *FIXED
*SHRPOOL2 .00 0 *FIXED
*SHRPOOL3 .00 0 *FIXED
*SHRPOOL4 .00 0 *FIXED
*SHRPOOL5 .00 0 *FIXED



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Jim Oberholtzer" <midrangel-zbO79nAUJZvJTQUaaPvyeQC/***@public.gmane.org>
To: "'Midrange Systems Technical Discussion'"
<midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 04:14 PM
Subject: RE: Performance considerations of a disk hosting lpar Was:

Disk: Percent full a performance factor?
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



Do you have the network servers using a pool identifier (I always use
*SHRPOOL50) to push the I/O memory there? That keeps it out of *BASE.

With 10TB of storage being hosted I have 4096 GB in that pool and that's
almost overkill. You might get away with 3Gb instead.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of
rob-***@public.gmane.org
Sent: Monday, October 20, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Performance considerations of a disk hosting lpar Was: Disk:
Percent full a performance factor?

On a loosely related note, what performance considerations should one
really
watch for on an lpar that does nothing but host disk? For example on our
Power 8's all disk (except to the vios lpars) is hosted by one lpar of IBM
i. This then hosts several lpars of IBM i and AIX.

RACK1HST: Hosts main production lpars
% CPU used . . . . . . . : 66.1
Auxiliary storage:
System ASP . . . . . . : 23277 G
% system ASP used . . : 54.3132
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 896.18 369.86 +++++ .0 .0 1.9 1.9
2 6329.73 14.27 145 .2 1.4 6.3 30757
3 811.89 .00 203 .0 .0 .6 2.3
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:37
%
Busy
0
0
0
...
For all 32 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK1HST 1 10 20 0.1 0.5 1 4 8
16


RACK2HST: Hosts Mimix lpars and backup Domino lpars.
% CPU used . . . . . . . : 5.1
Auxiliary storage:
System ASP . . . . . . : 22500 G
% system ASP used . . : 64.2344
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 781.05 362.50 +++++ .0 .0 3.6 3.6
2 6444.86 14.21 175 .0 .0 5.8 255.6
3 811.89 .00 203 .0 .0 1.5 6.4
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:39
%
Busy
0
0
0
...
For all 30 SSD units.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK2HST 1 10 20 0.1 0.5 1 4 8
12


RACK3HST: Hosts rarely used test lpar and a triple backup of our Domino
lpars.
% CPU used . . . . . . . : 19.7
Auxiliary storage:
System ASP . . . . . . : 5956 G
% system ASP used . . : 45.8444
System Pool Reserved Max -----DB----- ---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 691.21 352.51 +++++ .0 .0 .0 .0
2 6534.69 13.31 175 .0 .0 2.0 286.7
3 811.89 .00 203 .0 .0 1.2 8.1
4 81.18 .00 5 .0 .0 .0 .0
Work with Disk Status
Elapsed time: 00:00:29
%
Busy
0
0
0
...
for all 22 spinning disks.
Virtual Processors Processing units Memory
(GB)
Minimum Assigned Maximum Minimum Assigned Maximum
Minimum Assigned Maximum
RACK3HST 1 10 20 0.1 0.5 1 6 8
12



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Loading...