snmpcollector probe - performance tuning and optimization guidelines
Article ID: 9879
Updated On:
Products
Issue/Introduction
snmpcollector probe - performance tuning and optimization guidelines.
- Discussion of performance tuning and optimization guidelines for the snmpcollector probe.
Environment
- UIM 20.3 and above
- snmpcollector version 4.x or higher
Cause
- Guidance
Resolution
Excerpt from the Help doc on Performance and Scalability Considerations and additional notes from Support/Field.
The snmpcollector probe uses a large amount of memory and disk resources. For the best performance and scalability:
-
Install the snmpcollector probe on a remote hub. Do NOT install it on a robot and do NOT install it on the Primary hub. The hub that you use for SNMP data monitoring can have a significant impact on the performance and scalability of the probe. snmpcollector should be run from a hub because the spooler probe process is multi-threaded on hub.
-
Use manually configured hub queues to get the snmpcollector data back to the Primary hub. (Configure local ATTACH queue(s) on the remote hub, and configure GET queue(s) on the Primary)
-
Allocate sufficient memory and disk space to support your data collection requirements. The monitoring capabilities of the snmpcollector probe are limited if you install the probe on a small-scale system with a limited amount of resources. For more information about the minimum hardware requirements, see snmpcollector Hardware Requirements.
Memory:
Open the probe in Raw Configure mode, navigate to startup->opt and increase the memory settings on snmpcollector as long as you have sufficient physical memory to spare.
Larger environments:
-Xms6244m -Xmx8192m
Small to medium environments:
-Xms2048m -Xmx4096m - Only install snmpcollector with other monitoring probes if the other probes do not consume a large amount of system resources, e.g., such as storage probes.
For example, you can install the cdm and ntservices probes if the hub has sufficient resources. We do NOT recommend installing snmpcollector on a hub with other probes that can also consume a large amount of system resources. Some examples of these probes are vmware, icmp, and ibmvm. Use filters as much as possible rather than creating multiple templates. Filters let you control how the probe applies monitors based on attributes of the target device. Every template that you create is read separately by the probe. The probe uses a large amount of system resources to read EACH template.
If you don't have the required system and available resources in your environment, you might see a slowdown in data processing or failures in QOS collection.
In terms of what you plan on monitoring, please consider what metrics provide actual value for your environment/what metrics people will actually need to see and/or use in reports/dashboards. A sound strategy would include best practices/KPIs for given devices, e.g., routers, switches etc.
For example:
Routers and Switches:
- Availability
- CPU
- Memory Utilization
- Buffer Hit Stats
Load Balancers:
- CPU
- Memory
- Availability and Responsiveness
- Concurrent Sessions
- Connections per seconds
5. Polling (monitoring) intervals
Symptoms of a polling interval that may be too short might include when polling is taking > 5 minutes when the interval is already set to 5 minutes, and it causes the data points to be more
than 5 minutes apart.
6. Other performance considerations (Use of SNMPv1 versus SNMPv2/v2c)
What is SNMP v1?
SNMP v1 (also known as SNMPv1 or SNMP version 1) is the initial version of SNMP protocol. SNMP v1 is defined in RFC 1065 to 1067 and 1155 to 1157. It was developed by a small group of collaborators at a time when Internet standards and security were not paid much attention. SNMP v1 operates over UDP (User Datagram Protocol), IP (Internet Protocol), CLNS (OSI Connectionless Network Service), DDP (AppleTalk Datagram-Delivery Protocol) and IPX (Novell Internet Packet Exchange). SNMP v1 uses the authentication mechanism of transmitting a “community string” (i.e. a password) in clear text, which is very insecure.
What is SNMP v2?
SNMP v2 (also known as SNMPv2 or SNMP version 2) is defined in RFC 1441 to RFC 1452. SNMP v2 adds several improvements over SNMP version 1. They are improvements in performance along with advancements in security and confidentiality. It also adds improvements in the area of manager-to-manager communication. GetBulkRequest has been added to retrieve large data amounts by a single request. Earlier, you had to use GetNextRequest iteratively in order to get a bulk of data. However, many users believed that the party-based security system in SNMP v2 is too complex for their liking. This was the reason why it did not become popular.
SNMP v2c is the Community-Based Simple Network Management Protocol version 2. It is defined in RFC 1901 to RFC 1908. Actually, SNMP v1.5 was the initial name given to this protocol. The main difference between SNMP v2 and SNMP v2c is the security model. SNMP v2c uses a simpler community-based security model (found in SNMP v1). Apart from this difference in the used security model, SNMP v2c can be considered almost similar to SNMP v2. In fact, SNMP v2c is now regarded as the de facto SNMP v2.
What is the difference between SNMP v1 and SNMP v2?
SNMP v2 is the successor to SNMP v1. SNMP v2 has different message formats (differences in header and PDU formats) and protocol operations (two extra operations) compared to SNMP v1. SNMP v2 introduced the GetBulkRequest for retrieving a bulk of data at once. Both SNMP v1 and SNMP v2 are now considered obsolete. But, all SNMP implementations still support both SNMP v1 and SNMP v2.
Note that it is expected after an snmpcollector probe restart to not see all the QOS data for some profiles/OIDs/QOS objects, sometimes for hours, and up to 24 hours. This depends on how many devices are being monitored and the polling frequency/number of metrics being collected per instance of the snmpcollector probe.
First, the snmpcollector probe must discover all the devices and components and their related configurations to be monitored.
SNMPv2c allows bulk processing but SNMPv1 does not, so in general, SNMPv2 is preferable in terms of overall monitoring performance. Network factors will play a part as well, e.g., if there is any latency between the snmpcollector probe and the monitored devices so that should be considered and checked.
In some cases, it is recommended to deploy 2 or more instances of the snmpcollector probe, depending on how long it takes to complete the discovery after an snmpcollector probe restart.
Additional Information
SNMPv1 tends to be slower than v2 and v3.
Many important data structures in MIBs are expressed as multi-valued data. One example is the entries in a routing table. With v1, these can only be retrieved by sending multiple GetNextRequest messages. Each message gets a single table item.
snmpcollector Memory and Disk Requirements (broadcom.com)
For more information on MAX_BATCH = 5 see https://knowledge.broadcom.com/external/article?articleId=6137
Feedback
