OSI/MHS Configuration and Management Manual

Sizing and Tuning Your OSI/MHS Subsystem
OSI/MHS Configuration and Management Manual424827-003
8-9
Selecting and Allocating Physical Resources
Event Management Service (EMS)
Appropriate sizing for the Event Management Service depends on the size of the
system as a whole and the number of applications having different filter requirements.
The major issue specific to OSI/MHS is that enabling accounting events greatly
increases the number of event messages OSI/MHS produces. To optimize
performance, enable only the accounting events that you use for billing and
accounting. You can enable the other messages dynamically if you need to use them
for troubleshooting.
Most users assign an alternate collector to OSI/MHS rather than having OSI/MHS
event messages combined with messages from other subsystems. You can specify
separate collectors for accounting events and other events that OSI/MHS reports, or
you can use the same collector for all OSI/MHS event messages. You specify
collectors when you run the MHS manager process.
Selecting and Allocating Physical Resources
The size of the system required to run OSI/MHS depends on the volume of message
traffic and the processor type.
Memory
The minimum memory requirement to run OSI/MHS is about 32 MB per processor for
RISC systems, 16 MB for CISC systems. Because OSI/MHS demands a significant
amount of memory, the K122 (RISC) system is recommended for the minimum
configuration. A two-processor K122 system that has 32 MB per processor can
support a subsystem on the following scale:
2 MR groups
2 MS groups
2 RS groups
2 LO groups
2 GI groups
1 gateway, plus gateway users
500 MS users
More memory is required to support additional groups. Also, the memory requirements
increase for messages with content larger than 1 MB. For example, each GI group can
require up to 60MB of memory if configured for 10MB messages; for 2MB messages
the requirement is approximately 35MB per GI group. These figures apply to both
RISC and CISC systems.
If less memory is available, the number of messages processed is reduced.
Note. Adequate performance of this configuration depends on regular tuning, as described in
this section, and can be compromised by memory demand from other software running on the
same system.