I'd like to know about capacity planning for NetView/6000.
A large customer is complaining about NetView/6000 performance.
The account team has looked into the problem, analyzed the utilization
of some system resources(CPU, page space, real memory, etc), and
recommended the customer to upgrade the model and increase the memory
size.
The customer doesn't hesitate to increase system resources, but
he requests IBM development offer general guidelines to
size the models and estimate the memory/page space for NetView/6000.
I have seen the report "The NetView/6000 Sizing and Recommendations
Report, Oct 18 '93, by O.Michael Atogi, AIX Network Management
Development, RTP", which is available from MKTTOOLS.
It describes the rough recommendation for memory and page space
with the number of managed nodes. But, to talk about the model recomend-
ations, it only says faster machine is the best....
Do you know any other reports/guidelines which describe sizing NetView
/6000 V2.1? We need how to choose the model under certain situations,
and also need more detail memory/page space recommendation.
I received the new ATOGI document, and come to know it has been
revisioned from the old one seen in MKTTOOLS. Thanks.
The new report is quite nice for estimating DASD, page space, and
memory.
But we need some general measurements for choosing CPU models. (That
report compares the performance only among 320, 530, and 560)
The new report refers to how to calculate the required DASD with
arithmetic operation. But the customer wants to know such kind of thing
also for memory, swap space, and CPU models. I know such things are
hard to define when we face to the AIX platform, but anyway I'll
wait for the response.
ANSWER
Performance/Sizing guidelines:
You are on the best-track available that I know of, with the Atogi
document. I am afraid that there will not be a lot of other
"official" information available.
Quite often, the performance of AIX NetView/6000 will be affected by
other factors -- including which applications are running as part of
the AIX NetView/6000 family of products and, naturally, what other
applications / network traffic is running on the machine -- and,
perhaps, within the network itself.
In my experience, real memory and page space for the real memory have
been the key matters; but, our network is quite small.
All of the above comments are, though, of little value to you from
the point of view of sizing an environment... and responding to
a specific account team need. I realise an answer such as "the faster
and bigger that you can afford" is not sufficient -- but, I don't
hold out much hope for specific guidelines.
The following is development's currently final words on this subject.
This topic deserves additional action but I cannot promise when
someone will have resources which will be able to address the large
number of variables which are involved.
You are right, of course, that the only official document is what you
referenced.
I have this to add: Maybe SEs in the various trading areas need to
put a team together that gathers/gets data from Austin (AIX RISC/6000)
and Raleigh for management products and put together the comprehensive
chart that is badly needed.
There are basically 3 major parameters to size - memory (and paging),
disk, and CPU. Memory and paging we have provided to some extent.
BTW, the next point on the memory objects configuration table is:
128 MB, 22,673 objects
For CPU, I felt it would be easier for the SE
to size than me, since they are in touch with the customers and know
what the customers want plus SEs get the latest on RISC/6000 CPU models
faster than me -- so, my document did not get into that arena.
Next time, I will.
Here is some input on CPU. I have given the
same info to numerous SEs via notes.
CPU sizing consists of
(1) Traps/events processing. Typically, the bigger the network, the more
traps would flow to the management station. However, filtering can be
used to control/limit the trap rates. Unfortunately, this is something
the customer would decide. That's the customer is the one that would
decide which events/traps should be displayed, logged only, etc.
These are factors that influence the effective CPU. Again, in general,
the higher the trap rate the higher the CPU needed to keep up with the
processing. You can use this as a guideline:
A 340 with a clock speed of 33 MHz, would process an average of
60 traps per minute effectively
A model 560 with a clock speed of 50 MHz would effectively process
480 traps per min.
Note that these are averages. Depending on your level of
performance tolerance, it could be higher.
Also, if all the machine is doing is just sit there and receive
traps, those rates would be higher.
So, the user should understand the context in which I am writing from.
(2) Response to user request.
That is, when a user clicks a button to open a new submap,
how long does it take before the user actually sees the
submap?
Again, for a given workload, the faster the CPU the better the
response.... so, there is no real guideline available -- it depends
upon what is termed "good response" by that customer.
What size CPU should an SE recommend to a customer?
The answer to that question
is the sum of the memory sizing and the CPU issues discussed above.
It's really not a one solution for all thing that is why the SEs with
input from the customer best complete the exercise.
I can give numbers but they will not precisely suite individual cases.
For disk, paging space obtained from the memory configuration is one.
Estimates from products the user has or would install, for NetView/6000
is the user going to collect data, if yes, then I think I gave a formula
on estimating, for NetView/6000 internal databases,
about 1 MB per 900 objects with a standard deviation of 140.
.......................................................................
Additional comments on this topic came in from two different IBM SEs
who work closely with customers:
-------------------------------------------------------------------------
Subject: Capacity Planning in AIX NetView/6000 environments
From SE number 1:
Sizing, in fact isn't easy and most often we have to use 'best guess'.
But on the other hand we have to deal with other, not directly
performance related matters, which is also as much important.
I tell you how I do it (easiest first ) :
- Disk : I do not think that I need to calculate every byte which
will be used in a typical environment.
To my opinion it does not make sense to sell a disk less than
1GB today. This is not because of NV/6000 but for AIX.
Reason : Price, need to install PTFs, Code size increasing,...)
If there are other products installed on the system I tend to
use 2GB disk.
- Page space : This does not help to get performance - you just have to
have enough - or it crashes.
But if the disk is large enough (see Disk) this isn't
a problem. I use most often 100-200 MB.
- Memory : Follow guidelines in the mentioned report. But it is
equally important to recognize the physical limitations
of the different models. Do not fill up from the beginning.
i.e. a M 3X5 has one Memory slot .
M 3X0 has two Memory slot
M 250 use large SIMMs
I rarely use 'small' cards. I prefer to use steps
of 64 MB. Leave room to increase later.
- System : That's hard from the performance view - but less hard from
other factors. I made good experiences with 340/355 and
also with 250 now.
I tend to use a Net Mgt System with no other stuff on it.
If you look at the performance data for the different models
you see that now the 250 is the preferable system usually.
It is fast (compared to 340/35X/36X) and cheap. Price is
most often an issue.
I assume that the SPECint92 data is more important than
the SEPCfp92 for NV/6000. This is not mentioned anywhere.
In a future guide I would like to have a comment on this
issue (may be you can give the input).
(Comment on SPECint92 and SPECfp92:
..................................
Note: This has not been measured, but knowing what we do, this
is what is expected to happen:
AIX NetView/6000 processing involves the
Branch Processing Unit (BPU) and Fixed Point Unit (FXU)
mostly. There may be very little Floating Point Unit
(FPU) processing. We deal mostly with strings and integers;
therefore, a CPU with high SPECint92 (or whatever integer
benchmark used) would be a better performer than one with
high SPECfp92. Also, on a similar issue, a CPU with a
high data cache would be a better performer (because, to
manage a large network, NetView/6000 has to keep large
sums of data. If the data can be cached (and, with luck in
terms of locality of reference of the working set),
the performance would be better.
Again, all these are system parameters that can be obtained
from RISC/6000 land.
End: Comment on SPECint92 and SPECfp92)
.......................................
I think it is more important to have enough memory than
a faster CPU (they are not a lot faster anyway, but a lot
more expensive).
Conclusion : Although it is difficult to get numbers on
performance, because it is dependent on what you do -
it is not so difficult to choose the model. There are in
fact not so many models that make sense at all if you look
at price/performance data.
Further Comment : A very often asked issue is 'how NV/6000 loads the
network ? '. I know it is dependent on what you do
as well. But that's not a valid answer to a customer.
I would like to have a document discussing this issue
in more detail....
By IP tracing I got some basic info:
SNMP Get packet : usually 70 - 150 Bytes , typically <= 120 bytes
SNMP Response : usually 70 - 300 Bytes , typically <= 150 bytes
Ping (ICMP echo): 84 bytes
Demand Poll : SNMP Get's : 1600 Bytes
responses : 2100 - 3000 Bytes
( depends from the node )
All sizes are given in IP-Packet length (incl IP-Header). No frame
headers.
Maybe, somebody could do a more detailed follow up on this.
................................
From SE number 2:
Currently, I ALWAYS propose NetView/6000 V2 on machines like 250 or
360 as minimum CPU and 96 or 128 Mb of RAM.
For my customer situations, smaller machines are
not usable in production environment.
S e a r c h - k e y w o r d s:
PERFORMANCE
HR
CENTER
FONT size=2WWQA: ITEM: RTA000073427 ITEM: RTA000073427
BRDated: 12/1995 Category: ITSCSAIXNV6
BRThis HTML file was generated 99/06/24~12:43:27
BRComments or suggestions?
A href="../../../../feedback.html"BContact us/B/ABR
/FONT
/CENTER
/BODY
/HTML