IBM Tivoli Netcool Performance Manager Wireline Component Document Revision R2E2. Performance Guidelines IBM

Transcription

1 IBM Tivoli Netcool Performance Manager Wireline Component Document Revision R2E2 Performance Guidelines IBM

2 Note Before using this information and the product it supports, read the information in Notices on page 39. Copyright IBM Corporation 2010, US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

3 Contents About this information v Audience v Tivoli Netcool Performance Manager - Wireline Component v Service Management Connect vi Tivoli Netcool Performance Manager technical training vii Support information vii Conventions used in this publication vii Typeface conventions vii Chapter 1. Jazz for Service Management 1 Chapter 2. Tivoli Common Reporting.. 3 Chapter 3. Database space requirements 5 Chapter 4. Group density Effect Chapter 5. Collector Effect Multiple SNMP DataLoad collectors Effect Guidelines for multiple collector environment.. 11 Chapter 6. Formulas Effect Chapter 7. Optimizing the DataChannel Hourly Database Loader (LDR) Hourly Database Loader (LDR) Default behavior Optimized behavior Examples Configuring default or optimized behavior Guidelines for collector load balancing Chapter 8. Metadata tables Effect Chapter 9. Composite Subelements.. 23 Effect Chapter 10. Subgrouping Effect Chapter 11. Resources and inventory profiles Effect Chapter 12. Reports Resource Summary Table (RST) Reports Time Series reports Resource Time Series (RTS) Group Time Series (GTS) Advanced Group Time Series (AGTS) Multi-Resource Time Series (MRTS) Near Real Time (NRT) data Best practice for NRT TopN and BottomN reports 32 Matrix Report table Diagnostic view chart performance Optimal Time Series chart configuration Chapter 13. Default AIX memory limits 35 Effect Chapter 14. MDE Notices Terms and conditions for product documentation.. 41 Trademarks Copyright IBM Corp. 2010, 2015 iii

4 iv IBM Tivoli Netcool Performance Manager: Performance Guidelines

5 About this information IBM Tivoli Netcool Performance Manager is a bundled product that consists of two main components, a wireline component (formerly Tivoli Netcool/Proviso) and a wireless component (formerly Tivoli Netcool Performance Manager for Wireless). Starting from version 1.4, IBM Tivoli Netcool Performance Manager supports both Oracle and IBM DB2 databases. Attention: IBM DB2 is supported on Linux only whereas, Oracle is supported on Solaris, AIX, and Linux systems. This information describes how to get the best performance from your IBM Tivoli Netcool Performance Manager system. Audience The audience for this information is network administrator or operations specialist who would work on the Tivoli Netcool Performance Manager product suite on an enterprise network. You must have an understanding of the following subjects: v Basic principles of TCP/IP networks and network management v SNMP concepts v Administration of the Linux, Solaris, or AIX operating environment v Administration of the Oracle or IBM DB2 database management system v Tivoli Netcool Performance Manager Tivoli Netcool Performance Manager - Wireline Component IBM Tivoli Netcool Performance Manager consists of a wireline component (formerly Netcool/Proviso) and a wireless component (formerly Tivoli Netcool Performance Manager for Wireless). Tivoli Netcool Performance Manager - Wireline Component consists of the following subcomponents: v DataMart is a set of management, configuration, and troubleshooting GUIs. The Tivoli Netcool Performance Manager System Administrator uses the GUIs to define policies and configuration, and to verify and troubleshoot operations. v DataLoad provides flexible, distributed data collection and data import of SNMP and non-snmp data to a centralized database. v DataChannel aggregates the data collected through Tivoli Netcool Performance Manager DataLoad for use by the Tivoli Netcool Performance Manager DataView reporting functions. It also processes online calculations and detects real-time threshold violations. v DataView is a reliable application server for on-demand, web-based network reports. Copyright IBM Corp. 2010, 2015 v

6 v Technology Packs extend the Tivoli Netcool Performance Manager system with service-ready reports for network operations, business development, and customer viewing. The following figure shows the different Tivoli Netcool Performance Manager modules. Tivoli Netcool Performance Manager documentation consists of the following: v Release notes v Configuration recommendations v Installation and upgrade information v User guides v Technical notes v Online help The documentation is available for viewing and downloading on the information center at Service Management Connect Connect, learn, and share with Service Management professionals: product support technical experts who provide their perspectives and expertise. Access Network and Service Assurance community at developerworks/servicemanagement/nsa/index.html. Use Service Management Connect in the following ways: v Become involved with transparent development, an ongoing, open engagement between other users and IBM developers of Tivoli products. You can access early designs, sprint demonstrations, product roadmaps, and prerelease code. v Connect one-on-one with the experts to collaborate and network about Tivoli and the Network and Service Assurance community. v Read blogs to benefit from the expertise and experience of others. v Use wikis and forums to collaborate with the broader user community. Related information: vi IBM Tivoli Netcool Performance Manager: Performance Guidelines

7 Tivoli Netcool Performance Manager 1.4 community on developerworks Tivoli Netcool Performance Manager technical training Support information For Tivoli Netcool Performance Manager technical training information, see the following Tivoli Netcool Performance Manager Training website at: If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following ways for you to obtain the support you need: Online Access the IBM Software Support site at support/probsub.html. IBM Support Assistant The IBM Support Assistant is a free local software serviceability workbench that helps you resolve questions and problems with IBM software products. The Support Assistant provides quick access to support-related information and serviceability tools for problem determination. To install the Support Assistant software, go to support/isa. Troubleshooting Guide For more information about resolving problems, see the problem determination information for this product. Conventions used in this publication Several conventions are used in this publication for special terms, actions, commands, and paths that are dependent on your operating system. Typeface conventions This publication uses the following typeface conventions: Bold Italic v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text v Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Keywords and parameters in text v Citations (examples: titles of publications, diskettes, and CDs) v Words defined in text (example: a nonswitched line is called a point-to-point line) v Emphasis of words and letters (words as words example: "Use the word that to introduce a restrictive clause."; letters as letters example: "The LUN address must start with the letter L.") v New terms in text (except in a definition list): a view is a frame in a workspace that contains data. About this information vii

8 Monospace v Variables and values you must provide:... where myname represents... Bold monospace v Examples and code examples v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text v Message text and prompts addressed to the user v Text that the user must type v Values for arguments or command options v Command names, and names of macros and utilities that you can type as commands v Environment variable names in text v Keywords v Parameter names in text: API structure parameters, command parameters and arguments, and configuration parameters v Process names v Registry variable names in text v Script names viii IBM Tivoli Netcool Performance Manager: Performance Guidelines

9 Chapter 1. Jazz for Service Management Dashboard Application Services Hub is replacing the Tivoli Integrated Portal. Jazz for Service Management contains the following components: v Administration Services v Dashboard Application Services Hub v Security Services v Registry Services v Administration Services UI v Reporting Services environment v Tivoli Common Reporting Note: The supported Tivoli Common Reporting is Jazz for Service Management includes installation media for Jazz for Service Management, IBM DB2, IBM WebSphere Application Server, and the Quick Start Guide. Related information: Jazz for Service Management on IBM Knowledge Center Copyright IBM Corp. 2010,

10 2 IBM Tivoli Netcool Performance Manager: Performance Guidelines

11 Chapter 2. Tivoli Common Reporting Tivoli Netcool Performance Manager data model extends technology pack data model for Tivoli Common Reporting. After you install a technology pack, you use Framework Manager to open and create the corresponding Tivoli Netcool Performance Manager data model to enable Tivoli Common Reporting. Tivoli Common Reporting is based on IBM Cognos Business Intelligence, an enterprise reporting solution. It delivers a subset of IBM Cognos Business Intelligence function as a common reporting platform or across the Tivoli portfolio. By using Tivoli Netcool Performance Manager JDBC Driver, you can extend the domain-specific reporting capabilities of technology packs to Common Reporting by deploying Tivoli Netcool Performance Manager JDBC Driver on your system. Tivoli Netcool Performance Manager JDBC Driver consists of the following features and capabilities: Exposed Tivoli Netcool Performance Manager views v Group summary table (GST) v Resource Time-series table (RTS) v Resource Aggregated Time-series table (RATS) Improved performance v Replace Cognos XML data source with the Tivoli Netcool Performance Manager JDBC Driver v Support SQL-Select to query the required data Improved usability v Tivoli Netcool Performance Manager virtual tables such as GST, RTS, RATS are exposed through JDBC reflection API. Based on this JDBC reflection API, Cognos data model are created by using IBM Cognos Framework Manager. v The data models that are created are simple to create, use, and manage. Copyright IBM Corp. 2010,

12 4 IBM Tivoli Netcool Performance Manager: Performance Guidelines

13 Chapter 3. Database space requirements For Oracle and IBM DB2 database space requirements, see Configuration Recommendations. Copyright IBM Corp. 2010,

14 6 IBM Tivoli Netcool Performance Manager: Performance Guidelines

15 Chapter 4. Group density Effect Group density is the average number of time zone-enabled groups that a resource belongs to. v Group 1 Resource1 Resource2 v Group 2 Resource2 Resource3 v Group 3 Resource2 Resource3 In the example: v Resource1 has a group density of 1. v Resource2 has a group density of 3. v Resource3 has a group density of 2. The average group density for all the resources in the deployment is 2 (1+3+2) / 3 Describes the effect of group density performance guidelines. Affected components Group density performance guidelines impact DataChannel, DataLoad, and DataMart. When you build or update a grouping structure, give careful consideration to the impact that group density can have on the following areas: CME memory usage Affects DataChannel. The Complex Metric Engine (CME) builds a tree in memory to calculate RA (resource aggregation) records. (The CME also keeps the last 2 hours of NRAW (raw) data for the near-real-time function.) This tree is based on a combination of the requests and time-zone deployments. The key of an RA record is: v Metric ID, Resource ID, Group ID The higher the group density, the more memory the CME uses, since there are more RA records to calculate for a given metric/resource combination. For example, if the group density doubles, the number of RA records doubles, and the memory that is required to store those records also doubles. Copyright IBM Corp. 2010,

16 ECMAscript based formulas in the CME provide a means of aggregating data over arbitrary periods of time. The more inputs that an ECMAscript formula requires, the more memory that is required for each deployed instance of that formula. For example, consider a formula that aggregates over one month, that has two inputs that produce values every 15 minutes, and that is deployed against 1000 resources. That formula would require the CME to buffer 5,952,000 tuples in memory (4 values/hr * 2 inputs * 24 hrs/day * 31 days/mo * 1000 instances). CME throughput Affects DataChannel. Updating each RA record incurs a processor cost. The more RA records to update, the more processor cycles are required to perform those updates. In addition, poorly written formulas can consume an excessively large amount of processor. CME throughput is typically described in terms of raw records per minute. The higher the group density, the fewer raw records that the CME can process in a given time interval. Effective throughput is reduced as the group density increases. LDR throughput Affects DataChannel and database. As stated earlier, a higher group density yields more RA records. More RA records to load means more work for the LDR and more database processor resources that support the load. This increase in density leads to a lower effective throughput. Database space Affects database. As stated earlier, a higher group density yields more RA records. Therefore, more database space and required to store the records. 8 IBM Tivoli Netcool Performance Manager: Performance Guidelines

17 Chapter 5. Collector Effect SNMP collector performance is measured in OIDs per minute. The key metrics that affect the collector performance are as follows: v Number of OIDs to discover and collect v The balance between the number of devices and the number of OIDs per device v Network/devices latency v Drop rate v Grouping structure of the subelement collect branch When you write discovery formulas and collection formulas, and deploy the requests, check if all requested OIDs that are used in the collection are necessary. Ensure that the requests are deployed efficiently. Describes the effect of collector performance guidelines. Affected Components Collector performance guidelines impact DataLoad. The key metrics that affect collector performance are as follows: Number of OIDs to collect Unnecessary collection of OIDs causes the collector to expend resources that can be used to perform more collection or discovery. This unnecessary collection has a direct impact on collector throughput. Resources that are spent on a single unnecessary OID might not seem like much, but wasted resources accumulate quickly as the frequency of collection and discovery increases. The balance between the number of devices and the number of OIDs per device Devices require objects to be created and scheduled, which consumes processor resources. Also, collector startup time increases as the number of devices increases. Generally, as the number of devices increases, the demand on processor resources increases. Network/device latency Collecting unneeded OIDs on a slow network or device further lowers the effective throughput of the network or device. Drop rate Ensure that you have adequate bandwidth for collection, when possible. Grouping structure of the subelement collect branch The collector optimizes OID collection within a properly deployed grouping structure. The collector examines the OIDs for a given set of metrics, and collects each OID only one time if multiple formulas share a common OID. Copyright IBM Corp. 2010,

18 For example, consider the OIDs associated with following metrics: v Metric 1: OID A and OID B v Metric 2: OID A and OID C If metric 1 and metric 2 are deployed on the same collection group, the SNMP collector collects OID A only one time. However, this statement is true only if Metric 1 and Metric 2 are deployed on the same collection group. Polling Interval A small polling interval can degrade performance. The smaller the polling interval, the more frequently the collector must obtain the same OIDs. Multiple SNMP DataLoad collectors Starting from Tivoli Netcool Performance Manager 1.4, you can add and configure multiple SNMP collectors on the same host. In the previous Tivoli Netcool Performance Manager releases, you could have only a single SNMP collector per host. This restriction is not applicable for UBA collectors. Effect Describes the advantages of multiple SNMP DataLoad collectors. Starting from Tivoli Netcool Performance Manager 1.4, you can have multiple collectors per host. It helps in reducing the server resources required. In certain customers sites, they have up to 40 SNMP collectors that require 40 hosts (any of which might be virtual hosts). The current scenario where multiple collectors are allowed on a single host drastically reduces the number of servers (physical or virtualized) but does not change the disk, memory, or processor requirements. It makes the solution cost-effective with minimum changes to the topology to accommodate for service providers with their current network and also for service providers with growing networks. With the onset of multiple core processors, the computer hardware architecture brought changes in how Tivoli Netcool Performance Manager scales. Tivoli Netcool Performance Manager used to scale by adding commodity hardware. It was not necessary to have multiple SNMP DataLoad collectors on a single system. Now the commodity hardware is frequently a 4-16 core machine. Therefore, this change adds value to Tivoli Netcool Performance Manager scalability. Benefits of having multiple collectors on a single host: v Reduced number of operating system instances v Reduced cost reduction in licensing, support, and maintenance v Less complex upgrade process 10 IBM Tivoli Netcool Performance Manager: Performance Guidelines

19 Guidelines for multiple collector environment Guidelines for multiple collector environment v The maximum collector identification number is 999. v The collector numbers 500 and 501 are reserved and must not be used. For example, SNMP.x.500 and SNMP.x.501. v There is no relationship between the channel number and the collector number (that is, there is no predefined range for collector numbers based on channel number). Therefore, collector 555 can be attached to DataChannel 7. v Each database channel can have a maximum of 40 subchannels (and therefore, 40 collectors). v Maximum number of SNMP collectors is 16 per host. v The maximum number of DataChannels that can be created is increased to 16. In the earlier version, this number was 8. v Memory that is required for each collector is 4 GB. v The range of port numbers that can be used for the collectors is v All the collectors numbers must be unique. Chapter 5. Collector 11

20 12 IBM Tivoli Netcool Performance Manager: Performance Guidelines

21 Chapter 6. Formulas Effect The number of deployed formulas has a significant impact on performance. Ensure that all deployed formulas are used, whether for reporting purposes or for intermediate calculation (CME formulas). Describes the effect of formula performance guidelines. Affected components Formula performance guidelines impact DataChannel, DataLoad, and DataMart. The number of deployed formulas impacts the following areas: CME memory usage Affects DataChannel. The CME builds a tree in memory to calculate RA records. The CME also keeps the last 2 hours of NRAW data for the near-real-time function. The key of an RA record is: v Metric ID, Resource ID, Group ID The key of an NRAW record is: v Metric ID, Resource ID When you deploy more formulas, more memory is used by CME. You have extra NRAW records to store and extra RA and GA (group aggregate) records to calculate for a resource or a group. If the number of deployed formulas increase, the number of NRAW, RA, and GA records increases, and the memory that is required to store those records also increases. ECMAScript based formulas in the CME provide a means of aggregating data over arbitrary periods of time. The inputs that an ECMAScript formula requires increase and the more memory that is required for each deployed instance of that formula also increases. For example, consider a formula that aggregates over a month, has two inputs, whose inputs produce values every 15 minutes, and is deployed against 1000 resources. This formula requires the CME to buffer 5,952,000 tuples in memory (4 values/hour * 2 inputs * 24 hours/day * 31 days/mo * 1000 instances). CME throughput Affects DataChannel. Updating the various trees in memory incurs a processor cost. The more metrics there are to maintain, the more NRAW, RA, and GA records there are to process. Deploying unneeded formulas takes valuable CME processing time away from other resources. In addition, different formulas take different amounts of processor and it is possible to create poorly written formulas that take large amount of processor. Copyright IBM Corp. 2010,

22 Collector processor during collection and discovery Affects DataLoad. The impact of unneeded formulas is like the impact that is described in Chapter 5, Collector, on page 9. LDR throughput Affects DataChannel and database. More metrics to maintain means more NRAW, RA, and GA records to process and more database processor resources to support the load. This results in fewer resources that an LDR can process and a lower effective throughput. Note: For more information, see Hourly Database Loader (LDR) on page 15. Database space Affects database. When you more metrics to maintain, you also have extra NRAW, RA, and GA records that are written to the database. Therefore, the database space requirement to store the records is high. 14 IBM Tivoli Netcool Performance Manager: Performance Guidelines

23 Chapter 7. Optimizing the DataChannel Hourly Database Loader (LDR) This information describes the behavior of the DataChannel Hourly Database Loader (LDR), and provides instructions for configuring the default or optimized LDR behavior. Hourly Database Loader (LDR) Default behavior Every hour, the DataChannel Hourly Database Loader (LDR) collects metric data from files that are produced by the CME and loads the data into the database. When in the database, the data is available for display in views and reports. Latency is the time that is required to collect the data and load it into the database. Latency is measured for the different kinds of data that the LDR processes. Data types include raw data (NRAW), daily aggregated data (1DRA, 1DGA), weekly aggregated data (1WRA, 1WGA), and monthly aggregated data (1MRA, 1MGA). Data types are loaded sequentially, in the following order (starting from the left): NRAW, 1DRA, 1WRA, 1MRA, 1DGA, 1WGA, 1MGA Because data types are loaded sequentially, loading of 1DRA data cannot begin until loading of NRAW data is finished. Loading of 1WRA data cannot begin until loading of 1DRA data is finished, and so on. By default, the LDR attempts to refresh (collect and load) all this data every hour over the duration of the LDR period (daily, weekly, or monthly). The data refreshed each hour is an intermediate approximation of what the final value is at the end of the period. By default, the LDR attempts to refresh (collect and load) all this data every hour over the duration of the LDR period (daily, weekly, or monthly). The data refreshed each hour is an intermediate approximation of what the final value is at the end of the period. In most cases, the LDR can collect and load all the intermediate data well within the hour time frame. That means DataView reports can typically display data that is less than one hour old. However, on networks with many resources, it is possible that the LDR might have more data to collect and load than it can manage in a single hour. In that case, the default LDR behavior is as follows: v The LDR finishes processing the data type it was working on at the end of the first hour. For example, if the LDR was processing 1WRA data when the first hour ended, it finishes processing the 1WRA data at the beginning of the second hour. v If processing of any data type might not be started in the first hour, that data is bypassed. v When the LDR finishes the operation it was working on at the end of the previous hour, it begins processing the new hour's data, beginning with NRAW. Copyright IBM Corp. 2010,

24 Optimized behavior For example, if the LDR begins the second hour finishing 1WRA data, it would then attempt to load the current hour's NRAW, 1DRA, 1WRA, and 1MRA data. The impact is as follows: v When there is more than an hour's worth of data to process, the spillover into the second hour means that new data in the second hour is loaded into the database later than if there were no spillover. For example, suppose that the LDR is not finished processing 1WRA data until 5 minutes into the next hour. Because processing of the new hour's NRAW data cannot begin until the previous hour's 1WRA data is finished, it takes an extra 5 minutes to load the current hour's NRAW data into the database. Further, because processing of the current hour's 1DRA data cannot begin until the NRAW processing is finished, 5 minutes are also added to the effective latency of the 1DRA data, and so on. v When intermediate data needs to be bypassed, priority is given to short-term data NRAW and 1DRA. The longest data type, 1MRA, is bypassed first, and if necessary, then 1WRA, and finally, 1DRA. Note: NRAW data is never bypassed. Also, end-of-period data is never bypassed. Only intermediate hourly data might be bypassed if there is more data than the LDR can manage in a given hour. Optionally, you can change the default LDR behavior to optimized behavior. The LDR optimized behavior is as follows: v NRAW, 1DRA, and 1DGA data is collected and loaded every hour (as it is by default). v 1WRA and 1WGA data is collected and loaded one time every 6 hours, rather than every hour. v 1MRA and 1MGA data is collected and loaded one time every 24 hours, rather than every hour. By refreshing 1WRA/1WGA and 1MRA/1MGA data less frequently, you reduce LDR usage in each hour. The efficient LDR usage frees up time for refreshing the short-term data, NRAW and 1DRA/1DGA, at or nearer to the beginning of each hour, and lessens the chance of having to bypass data in any hour. Depending on network configuration and other factors, optimizing LDR behavior can reduce LDR usage up to about 40% for a number of resources. Before full LDR usage is reached, and you risk bypassing data and adding to the time needed to load a new hour's NRAW and 1DRA/1DGA data. Your network can include up to about 60% more resources than it might with the default LDR behavior. 16 IBM Tivoli Netcool Performance Manager: Performance Guidelines

25 Examples The following examples illustrate the differences between default and optimized behavior. Example 1 The following figure shows the default behavior for a given load. In this example: v The LDR attempts to load all available data (NRAW, 1DRA, 1WRA, 1MRA) every hour. v Given the amount of resources on the example network, the LDR requires 3 minutes to load the available NRAW data, and 9 minutes each to load the aggregated data 1DRA, 1WRA, and 1MRA. v Because the data types are loaded sequentially, the effective latency for each data type is computed as follows: Table 1. The default behavior for a given load. Data Type Actual Time Required to Load Data Type Effective Latency Computation of Effective Latency NRAW 3 minutes 3 minutes Processing starts immediately at the start of each hour therefore, the effective latency equals the actual time that is required to process. 1DRA 9 minutes 12 minutes Processing starts when NRAW processing ends therefore, the effective latency is 3 minutes plus 9 minutes. 1WRA 9 minutes 21 minutes Processing starts when 1DRA processing ends therefore, the effective latency is 12 minutes plus 9 minutes. 1MRA 9 minutes 30 minutes Processing starts when 1WRA processing ends therefore, the effective latency is 21 minutes plus 9 minutes. v Because it takes a total of only 30 minutes to load all the data, the LDR successfully loads all data every hour. Chapter 7. Optimizing the DataChannel Hourly Database Loader (LDR) 17

26 Example 2 The following figure shows the optimized behavior for the same load as in the previous example. With optimized behavior: v The LDR loads only NRAW and 1DRA data every hour. 1WRA is loaded every 6 hours, and 1MRA data is loaded every 24 hours. v Given that the amount of resources on the network is the same as in the previous example, the LDR again requires 3 minutes to load the available NRAW data and 9 minutes each to load the aggregated data. v In Hour 1, the effective latency for each of the data types is the same as it is in every hour of the previous example. v In Hours 2-6, only NRAW and 1DRA data is loaded. In these hours, the effective latency of each data type is the same as in Hour 1. v In Hour 7, 1WRA data is also loaded (in addition to the NRAW and 1DRA data). Because 1WRA data is loaded for the first time since Hour 1, the effective latency for the 1WRA data is 6 hours, 21 minutes. Example 3 The following figure shows the optimized behavior with four times the load as in the previous examples. Given this amount of resources on the example network, the LDR requires 12 minutes to load the available NRAW data, and 36 minutes each to load the aggregated data. 18 IBM Tivoli Netcool Performance Manager: Performance Guidelines

27 The LDR behaves as follows: v In Hour 1, the LDR attempts to load the data for all the data types, but cannot do so. As Hour 1 ends, the LDR still has 24 minutes of processing left for 1WRA data. v At the beginning of Hour 2, the LDR completes 1WRA processing from the previous hour. It then begins processing the Hour 2 NRAW data 24 minutes late. B Note: Because the LDR did not start to process the 1MRA data in Hour 1, that 1MRA data is bypassed. 1MRA data is not processed until the LDR has free time at the end of a subsequent hour. Also, when 1MRA data is finally processed, it is more current than the 1MRA data that cannot be processed in Hour 1. v As Hour 2 ends, the LDR still has 12 minutes of processing left for the Hour 2 1DRA data. v At the beginning of Hour 3, the LDR completes 1DRA processing from the previous hour. It then begins processing the Hour 3 NRAW data 12 minutes late. v As Hour 3 ends, the LDR finishes processing all the Hour 3 1DRA data. None of the Hour 3 data needs to be finished in Hour 4. v In Hour 4, the LDR is able to process all the data that is scheduled for Hour 4, and finishes with 12 minutes remaining in the hour. It therefore begins processing 1MRA data from the current hour because 1MRA data was bypassed in Hour 1. v In Hour 5, the LDR requires an extra 24 minutes to finish processing the 1MRA data from the previous hour. Further, because processing of 1MRA data began 3 hours and 48 minutes late, the effective latency of the 1MRA data is 4 hours and 24 minutes (264 minutes). v In Hour 7, the LDR is scheduled to process 1WRA for the first time since Hour 1. It can process 12 minutes of the 1WRA data in Hour 7, and finishes processing the remaining 24 minutes in Hour 8. The effective latency of the Hour 7 1WRA data is 7 hours and 24 minutes. Chapter 7. Optimizing the DataChannel Hourly Database Loader (LDR) 19

28 Configuring default or optimized behavior You configure the LDR for default or optimized behavior by opening the Tivoli Netcool Performance Manager Topology Editor and editing the configuration parameter AGGREGATION_FIDELITY for each CME. About this task This parameter has two valid values: v HIGH. Default LDR behavior. v LOW. Optimized LDR behavior. For information on changing configuration parameters in the Topology Editor, see the Installing Tivoli Netcool Performance Manager - Wireline Component. Guidelines for collector load balancing You can optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource by load balancing. Decreasing the poll interval value increases the frequency of the polling. More frequent polling introduces surplus to run the poll, but more timely data is provided. If you want to increase or decrease the polling time, first get the NMON data and proviso log information to perform the details performance analysis, to determine the related DataLoad and DataChannel component's resource utilization and performance summary. As general recommendation, the system can have 40,000 subelements per subchannel with an average of 10 metrics per subelements with a 15-minutes granularity period. Consider the following guidelines: If you want to set the granularity period to 5 minutes, you need to increase the number of subchannels. This setting allows each of the subchannels to be able to process the data within the 5 minutes. Essentially, it decreases the number of elements per subchannel. If the granularity period is reduced to 5 minute, then number of subelements per subchannel can be reduced. Note: It is suggested to contact services and PMG team for further guidelines. 20 IBM Tivoli Netcool Performance Manager: Performance Guidelines

29 Chapter 8. Metadata tables Effect Most metadata tables in the Tivoli Netcool Performance Manager database have two versions one tracks the current view and the other tracks the history. Unnecessary rows in the history table increases system resource utilization, slows down access, and decreases overall system scalability. Describes the effect of metadata table performance guidelines. Affected components Metadata table performance guidelines impact database and DataMart. If unnecessary updates occur on the metadata tables, the historical versions of these tables grow larger than they need to, since every change is tracked. The impact on the system is as follows: v Access to the historical versions of these tables involves sifting through a significant amount of data to find the appropriate row. Unnecessary updates that are stored in the history tables increase the number of rows that must be examined when you attempt to access the correct row. It results in extra work that the database server must perform to satisfy the query. Even with using indexes, the workload is significant. v As the number of rows increases, the database space that is required to store these changes also increases. There are many causes of unnecessary database updates. One common example occurs when one resource is discovered by multiple profiles. When a resource is discovered, the profile name and the collector number are stored in the database as part of the attributes of the resource. If the resource is continually discovered by multiple profiles, the profile name and collector number keep changing with each discovery. This duplication causes a massive number of unnecessary history records. For more information about this cause of unnecessary database updates, see Chapter 11, Resources and inventory profiles, on page 27. Another common example of unnecessary database updates is using the resmgr command to overwrite data that is discovered during inventory. The problem here is that each time inventory is run, the values are overwritten with the ones discovered in the network. While reapplying, the same resmgr update can return the values to the wanted state, it introduces significant churn into the history tables. If you need to adjust inventory data, you must use the inventory hook process. Copyright IBM Corp. 2010,

30 22 IBM Tivoli Netcool Performance Manager: Performance Guidelines

31 Chapter 9. Composite Subelements Composite Subelements (CSEs) are Tivoli Netcool Performance Manager entities that describe the relationships and dependencies between inventory objects in a network service. CSEs are subelements that have defined relationships with other subelements. As mentioned earlier, the resource ID is part of the key of NRAW and RA records. Increasing the resource counts has a direct impact on database size, CME memory, and CME performance. These factors need to be considered when you size a system that uses CSEs. Effect Describes the effect of composite subelement performance guidelines. Affected components Composite subelement performance guidelines impact DataChannel, DataLoad, database, and DataMart. A single subelement path is not represented by a single object. The simplest path model yields at least three subelements, one subelement is created for the path itself, and one subelement is created for each endpoint in the path. If you need to monitor each direction of the path, two subelements are created to represent each path direction, and one subelement for each endpoint in the path. Therefore, four subelements are needed to represent one path. Note: CSE is complex and can have a noticeable impact on performance. For more information about CSEs, see the Composite Subelement Configuration. Copyright IBM Corp. 2010,

32 24 IBM Tivoli Netcool Performance Manager: Performance Guidelines

33 Chapter 10. Subgrouping Effect With the subgrouping feature, you can run a subset of the grouping rules that apply to a given profile, rather than all the grouping rules in a grouping tree. For example, you can define subgrouping rules that are based on the underlying technology (such as interface speed or vendor devices) or that are business-oriented (such as customer name or location), depending on what makes the most sense for your deployment. In other words: v Why run grouping rules against a customer name when you know none of the resources you just discovered are related to a particular customer? v Why run grouping rules for Juniper when the profile targets only Cisco devices? Describes the effect of subgrouping performance guidelines. Affected components Subgrouping performance guidelines impact database and DataMart. Currently, grouping consumes a relatively large amount of processor. This load might not be obvious in a small deployment, but it becomes clear in a large one. One reason for the large processor usage is that grouping runs every grouping rule every time it runs, even if some of the grouping rules have nothing to do with the profile in question. Subgrouping addresses this issue. Copyright IBM Corp. 2010,

34 26 IBM Tivoli Netcool Performance Manager: Performance Guidelines

35 Chapter 11. Resources and inventory profiles Effect Assign a resource to one inventory profile only. If you assign a resource to more than one inventory profile, the database record for that resource is continually modified. Describes the effect of resources and inventory profiles performance guidelines. Affected components Resources and inventory profiles performance guidelines impact DataMart and database. The inventory profile name is one attribute of a resource definition. When an inventory is run, the profile name that is stored in the database is compared to the name of the profile being run. If the names do not match, the database record is updated with the name of the profile being run. Each update to the database generates a history record. It means that extra rows are added to the history tables, even though no resource information is changed other than the profile name. The more history records for a given resource that Tivoli Netcool Performance Manager is required to manage, the slower the performance. For instance, suppose that you share a resource between two profiles (profile X and profile Y). Profile X runs at 06:00 and 18:00, and profile Y runs at 00:00 and 12:00. The resource configuration is stable, so the inventory detects no change in the resource itself. However, since the name of the profile discovering the resource keeps changing each time that an inventory is run, the database record for the resource is continually updated to reflect the profile that last discovered it. Each update to the database adds a row to the history table in this example, four rows per day: v Day 1: 06:00 > Update record with a profile name of X 12:00 > Update record with a profile name of Y 8:00 > Update record with a profile name of X 00:00 > Update record with a profile name of Y v Day 2: 06:00 > Update record with a profile name of X 12:00 > Update record with a profile name of Y 18:00 > Update record with a profile name of X 00:00 > Update record with a profile name of Y v Day 3 06:00 > Update record with a profile name of X Copyright IBM Corp. 2010,

36 If this resource belongs to a single inventory profile, the number of rows in the history table that is associated with this resource would be exactly one (assuming the rest of the resource's attributes of the redo not change). But since the resource is assigned to two profiles, and the inventories run a total for four times per day, four history records are added to the database each day. Continuing with the example, suppose that this resource does not change for the entire year. It means that the history table must contain a single entry for this resource for the year. But because the resource is assigned to two profiles, the result is a larger number of history records: v In one week: 28 records (4 per day x 7 days) v In one month: 120 records (4 per day x 30 days) v In one year: 1460 records (4 per day x 365 days) This example illustrates only a single resource. The performance effect degrades if hundreds of resources are assigned to multiple inventory profiles. For more information about the impact of managing unnecessary history records, see the Chapter 8, Metadata tables, on page 21 section. 28 IBM Tivoli Netcool Performance Manager: Performance Guidelines

37 Chapter 12. Reports Describes the effect of report performance guidelines. Affected components Report performance guidelines impact database processor as well as the time required to display views and reports. The performance of DataView reports depends largely upon three major factors that are involved in the retrieval and processing of the information to be displayed in the reports: v The number of tables or charts included in the report For each component (for example, table, chart) included in the report, information to populate that component must be queried from the database (and potentially from DataChannel). Each component is populated sequentially, and the report is not displayed until all components are populated. The more components that are included in the report, the more time is required to display the report. v The amount of processing that can be performed in the database by the queries that are used to populate the report components DataView queries are optimized to retrieve information from the database as efficiently as possible. Additionally, queries implement features such as sorting and paging to use functionality available within the database. The intent of such feature implementations is to restrict the amount of data that is retrieved from the database to only the information that is to be displayed in the report. Some reports offer the ability to include Near Real Time (NRT) data in the information to be displayed. In these situations, DataView requests information from DataChannel over the network. NRT data must therefore be formatted for transmission over the network, reformatted for processing, and then merged with the data retrieved from the database. This processing that occurs outside of the database adds to the overall time required to display the report. Content designers must consider the potential effect on performance when they enable the inclusion of NRT data in reports. v The amount of information to be processed The performance of the report is related to the amount of data that must be queried or processed. Whenever possible, DataView populates reports with the aggregated data that exists in the database, therefore minimizing the amount of data that must be processed before a report is displayed. Aggregated data exists for both groups and resources at periods of one day, one week and one month. When populating a table in a report, the query uses an aggregation period relative to the length of the reporting period: Daily aggregation for daily reporting periods Weekly aggregation for weekly reporting periods Monthly aggregation for reporting periods of one month or greater When populating a line chart in a report, the query determines the aggregation period that is based on the granularity of the data points to be displayed in the Copyright IBM Corp. 2010,

38 line chart. The granularity setting (the length of time between data points in the chart) is independent of the length of the reporting period: Daily aggregation for granularity of one to six days Weekly aggregation for granularity of one week Monthly aggregation for granularity of one or more months Raw data for granularity of less than one day Note: Raw data significantly increases the amount of data to be processed. As the length of the reporting period increases, so does the amount of raw data to be processed. Content designers and report users must consider the potential effect on performance when they use a granularity setting of less than one day, particularly for reporting periods of one month or longer. More factors that can affect the performance of DataView reporting include: v Report deployment and navigation It is recommended that Group Summary Table (GST) and Resource Summary Table (RST) reports be deployed as a means of traversing the report hierarchy. These summary reports can be used to navigate to the lower levels of the hierarchy where a smaller subset of the resources within the hierarchy can be reported upon with greater detail. v The number of resources that are presented in the report Generally, the more resources in a report, the longer it takes to display the report. It is true with reports that contain raw data or most recent values. v The number of child groups at the next level of the group hierarchy The time that is required to display the list of groups in the Navigation column on the portal increases as the number of groups in the list increases. Resource Summary Table (RST) Reports Performance considerations for RST reports include: v The more resources in the group that the RST is run against, the longer it takes for the RST to run. v An RST containing lastvalue, lasttime, or BurstViolation statistics can display more slowly than other RSTs, as this information must be retrieved from DataChannel. v An RST reporting upon composite subelements (CSEs) displays more slowly as the number and complexity of CSEs in the system increases. Larger numbers of CSEs require the RST to query more metadata to retrieve the appropriate information to be displayed in the report. v Sorting an RST based on lastvalue, lasttime, or BurstViolation statistics can increase the time that is required to display the RST, since the sorting and paging functionality cannot be performed within the database. v Maintaining a manageable number of resources in the group tree below the point where the RST is deployed. Note: If you are designing an RST primarily for use as a search tool (for example, to use its sorting or name-based filtering capabilities), it is not recommended to deploy the RST against groups that contain more than 5,000 resources. If you need to have groups of this size in this type of report, consider using the resource search report. This report is designed to handle groups with large numbers of resources and is NOC-oriented. The resource search report is not a historical report. To provide acceptable performance, only the current information is queried. 30 IBM Tivoli Netcool Performance Manager: Performance Guidelines

39 Time Series reports Performance considerations for Time Series reports include: v If the granularity of the time series is less than one day, raw data is used to populate the chart. With raw data, the following factors affect the performance of the report. The longer the reporting period, the more data there is to process. The smaller the polling interval for the metric, the more data is collected and then processed. As the number of metric/statistic combinations to be displayed in the chart increases, so does the amount of data to process. The following sections describe more performance factors for specific types of time series reports. Resource Time Series (RTS) When granularity is set to less than one day, NRT data is automatically included in a current-period RTS report. The NRT data must be merged with the data retrieved from the database before the chart can be displayed. Group Time Series (GTS) v When granularity is set to less than one day, GTS reports can be optionally configured to include NRT data when the report is run for the current period. The NRT data must be merged with the data retrieved from the database before the chart can be displayed. v When granularity is set to less than one day, performance of the GTS report is directly related to the number of resources in the group. The GTS must retrieve and aggregate the raw data for all resources in the group. As the number of resources in the group increases, so does the amount of data to process. v When raw data is being retrieved, it is recommended that a GTS report contain no more than 100 resources, and possibly less, depending on varying factors in the deployment. Advanced Group Time Series (AGTS) v Due to the calculations performed, AGTS reports always use raw data, regardless of the specified granularity. v AGTS reports can be optionally configured to include NRT data when the report is run for the current period. The NRT data must be merged with the data retrieved from the database before the chart can be displayed. v Performance of the AGTS report is directly related to the number of resources in the group. The AGTS must retrieve and aggregate the raw data for all resources in the group. As the number of resources in the group increases, so does the amount of data to process. v It is recommended that an AGTS report contains no more than 100 resources, and possibly less, depending on varying factors in the deployment. Chapter 12. Reports 31