Users Guide

Best Practices: Performance Tuning Traffic Flow Analysis | Traffic Flow Analyzer
552 OMNM 6.5.3 User Guide
<attribute name="EnabledDNSLookup">true</attribute> <!--#Enabed DNS
lookup-->
<attribute name="SamplingRate">1</attribute> <!-- #Sampling Rate-->
<depends>oware:service=NotificationProcessingMBean</depends>
<depends>oware:service=HAServiceController</depends>
<depends>oware:service=ClusterPrimaryDesignator</depends>
<depends>jboss.j2ee:jndiName=RuleEngine,service=EJB </depends>
</mbean>
CAUTION:
Changes to this file do not persist if you upgrade. Best practice is to save a copy of the file elsewhere,
and re-copy it into the correct location after upgrading.
Using random sampling to deal with high-volume scenarios
If the volume of incoming traffic flow data is beyond what can be processed, you can tune displays
to optimize samplingRate. The sampling rate determines processing speed for incoming NetFlow
packets (this does not apply to sFlow packets). The sampling rate should be 1 if you want to try to
process everything. If the system is unable to keep up, then set this parameter higher, for example:
10, and restart the server. This makes OpenManage Network Manager process only 1 out of every
10 incoming NetFlow packet, at random. The object is to find the lowest value for this attribute
that still allows the system to fully process all records that it tries to process.
To enable this feature, add the following like to installed.properties with your chosen value of N to
the right of the equals sign and the restart the application server:
NetFlowListenerMBean.SamplingRate=
Advanced Performance Tuning
You might need to add entries to installed.properties to override the following system properties:
NetFlowListenerMBean. SpoolQueueMaxSize —The maximum number of traffic flow records
storable in the spool queue during internal processing. Such processing occurs after
OpenManage Network Manager receives them from the exporter and before they are saved to
the database. OpenManage Network Manager temporarily stores such records in the spool
queue if Traffic Flow Analysis receives more traffic flow packets from the exporter than it can
process at once. This allows Traffic Flow Analysis process these records later, packets arrive
more slowly. If packets consistently arrive at a faster rate than OpenManage Network Manager
can process them, the spool queue fills up and Traffic Flow Analysis discards them without
processing.
ta.ThreadPoolSize — The default number of threads working to process traffic flow data.
ta.MaxThreadPoolSize — The maximum number of threads working to process traffic flow data.
Traffic Flow Database Advice
Traffic flow records average 300 bytes. Retention policies determine how long they stay in your
database. So 1 minute flows, retained for 48 hours, 50% correlated (Correlation factors indicate the
percentage of flows across all one minute buckets being aggregated that correlate based on
conversation key data), mean 2.7 million flows per interval. If your retention keeps these 48 hours,
then there are 2,880 retained intervals, and 7,776,000,000 potential rows. These rows times the 300
byte record size equal 2,173G in space, and 45,000 inserts per second. Typically, retention is for 1
minute, 10 minute, hourly, daily and weekly intervals, so for an overall picture of database needs,
you would need to add all these intervals.