This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

NPM Sizing and Performance - Real life experiences

All,

I am planning a NPM development for 10.000 network devices (assuming they will have an average of 24 interfaces + CPU and memory). I've reading many documents about sizing and performance but

I'd like to read about real life experiences. I was discussing with some colleagues having a similar deploy and they are not so happy with NPM (perhaps because they didn´t maintain the database, applies patches or fixes, etc).

Any help, comment or information will be really appreciated.

Best!

Ivan

  • In our environment we have a mix of servers and network devices around 5000 devices monitored with around 70,000 elements monitored if not more. We have this across 7 pollers, 1 primary and 6 additional. And haven't had any problems since deployment. We forecast for future growth and over provisioned our vm's. This way we can account for growth without needing to upgrade anything. Vm's are not in the same host, they are spread out across 4 different hosts with the db being on a separate low use host with high fast storage.

    In theory (Dependent on variables such as intervals of polling etc) you should be able to pull upto 12000 elements per poller. Best practice it to keep it around 10000 elements and think about adding a new engine if you reach 11000 elements. Elements are a count of nodes, volumes, and interfaces all together. You also have a limit of 10000 components per poller if your doing sam monitoring for server related things.

    NPM is an awesome tool if it's deployed correctly. Pollers themselves normally do not need the fastest storage around but you gain performance benefits if you can fit them in. On the other hand you would want your database on the fastest storage you have available. I believe admin guide suggests separate drives for the mdf and ldf and temp db. And each on 15k sas drives or SSD's on a raid - 10 array.  The guides normally just give a general guidance. But the best thing is to assess your growth and your needs and custom build a system to support it. Just as a reference point our primary runs 24 vCPU's 40 gigs of ram and our APE's are all on 8 cores and 32 gigs of ram and running just fine. Our DB is on 24 cores and 100 gigs of ram and experiences no problems.

    I hope this helps for reference!