2 Replies Latest reply on Dec 30, 2008 6:50 PM by SGL3

    NetFlow Slow Performance / Reports

      One of our setups which uses the NetFlow module has two separate servers:

      DB Server=4GB RAM, 146GB RAID1 15K 3.0GHz single CPU

      Orion/Web Server (same box)=4GB RAM, 72GB, RAID1 15K 3.2GHz single CPU

      Running NetFlow reports takes upwards of 15 minutes depending on the time frame.  Example is NetFlow details last 3 months on a particular interface.  Very, very slow.

      The NetPerfMon DB is only 10GB, disk is not trashing, RAM has plenty to spare on both servers and CPU when running the reports is <10% on the Orion/Web and bounces between 30-40% on the DB server.  These servers are not having any utilization problems.

      What can be done to increase the report generation performance?

        • Re: NetFlow Slow Performance / Reports
          Andy McBride

          Looking a flows across an interface for a 3 month period is a lot of data. You could increase the report time by asking for a shorter time period,. Also running you drives in RAID 0 performs much better than RAID1.


            • Re: NetFlow Slow Performance / Reports

              Hi Andy,

              Not sure I'd run my DB on RAID 0 but I do have many other transactional databases running on MSSQL running on lesser machines that have much better performance.  Websense is a great example I have one location where the Websense DB is >12GB and report generation happens in seconds and there are many more records/transactions in that DB to search and report on than the NetPerfMon DB.

              I'd have to say I've pointed out our hardware setup only to communicate that hardware is not the problem here and really this looks like some type of an indexing and/or application issue that may benefit from some tweaks.

              Do you have any documents on configuring/managing the NetPerfMon database for best performance?  A 10GB SQL database on this hardware should not be having these long delays when pulling a report.

              Thanks, Steve