Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Netflow is killing my server, why?

It appears that way. But CPU and other metrics don't show the CPU pegged at 100% or even 50%.

Have orion 8.51sp3 with monitoring 162 nodes, 4,071 interfaces.

Netflow 2.2.1 is pulling data on 52 interfaces.

server is

Processor Name:	Intel(R) Xeon(R) CPU 5160 @ 3.00GHz (Dual Core)
Memory Installed:	4,094.98 MB

have my sql 2000 database on another server is a 4 cpu box with 4gigs of ram. netflow collection and sql are NOT on the same server. T

Trying to move around in an RDP session in npm or even Cirrus is sluggish with netflow service running. But taskman cpu does not show high utilization. If I stop netflow service, the lag which is about 1-2 seconds is gone.

The mystery here is I don't have the cpu getting crushed at 40-80%. The gigE interface is not even being pushed at 1%.

Where do I start trying to narrow down where my issue is? I only keep netflow data for 24 hours.

Thanks

Find more posts tagged with

Accepted answers

All comments

floyd.may

Check your physical memory utilization on the box, maybe something's eating your RAM.

d-moore

nope. not the issue. About 800meg being used by all 53 services on the box. Avail physical "ram" is about 3gigs, with pagefile ram is about 6gigs

Netperfmon about 215megs, w3wp.exe (iis) about 110megs, netflow around 45-50megs, etc

floyd.may

Something else has to be at work, then. See if you get any more information using this tool:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

aLTeReGo

Could the issue be disk I/O on the SQL server? That's what killed us when we brought NTA online. We had to move the Orion database onto a 4GB Fibre Channel EMC SAN RAID 10 volume built on 15k drives to relieve the I/O bottleneck that was created by adding NTA.

FormerMember

Question: what OS are you running your RDP session from? I'm guessing Vista because I had the same problem the first time I ran RDP after a new Vista install. This article saved my bacon. Basically, Vista RDP uses a new feature called "auto-tuning for the TCP/IP receive window", and it is BROKEN!!! As soon as I disabled it, all RDP slowness went away. You disable it by Running a command prompt (cmd.exe) as an Administrator, and type "netsh interface tcp set global autotuninglevel=disabled".

Let me know if that fixed it... -Scott

d-moore

Vista? what is that? There are actually people who run the WindowsME of 2006?

WinXP all the way. Skipping VistaME and going to Windows7 when it is released.

Thanks for the article, till I read it, would have called you crazy saying RDP and vista have issues.

Again, blame microsoft for release a product that wasn't read yet.

My problem was solved by purging my SQL database, shrinking it and limiting the growth of it.

bbusbey

NetflowService.exe is still a CPU hog on my SLX.

Even with 2 Xeon Dual core 3.00ghz, it is using 65% of the CPU.

It sure would be nice to move the process to another poller.

mcbridea

Hi Bruce,

We are looking at some architecture changes that will allow a second collector to off load the work. No dates to share at this point but we understand this can be an issue and are addressing it. The additional collector available today is designed for reachability issues and won't help much for processor.

Andy

mcbridea

Hi d-moore,

how is memory doing with the Netflow service running? Sounds like you have the potential for a large flow rate which can eat up resources.

Andy

d-moore

Thanks for asking, but I dumped your netflow services for Scrutinizer. It gives me more detail and I can run it on another lower powered server. Since I don't need to keep NF data more than 24 hrs, it isn't an issue to me that the freeware version dumps the data after 24hrs.

I am still running old reliable Orion 8.5.1. Plan to upgrade to 9.1 next year now that everyone has had a change to "debug it" on thier production systems.