Orion web console very slow despite RAM upgrade

We are testing Solarwinds NPM(10.3) & SAM . The system is a dedicated freshly formatted Windows 2003 SP2 server with Dual Core Xeon processor with 2 GB RAM (initially which was upgraded to 3 GB) and 200GB HDD free space. We are using the inbuilt SQL server and will be shifting to a dedicated database server once IF we decide to procure Solarwinds. Only 3 nodes have been added (11 interfaces). From day one, we have noticed that the Web console performance is very slow and the system RAM utilization close to 1.8 GB. We increased the RAM to 3GB however the web console performance is still slow. There are times when the console does not load at all. If we restart the services, the console works good for some time before the issue comes up again. Symantec endpoint is installed on the server, but is stopped since we thought it could be causing an issue but the performance did not improve. We also wanted to test the NTA and NCM components but have not installed because this issue might get worse. Any ideas why this could be an issue?

Ideally what would be the RAM requirement if we want to test all components? For the initial POC we would just be adding 5 routers(1 running netflow) and 3 Servers. I figure the server we are providing is decent enough for the POC before we decide to go for a full fledged config.

Find more posts tagged with

web_console

sam

slow_performance

orion

npm

Accepted answers

All comments

csm_carras

I ran into this issue previously and tech support told me it was because I was running SQL on our Orion server. They said we would see an improvement once we moved it off. We haven't done that yet, but I have spoken to a couple of other people that have had the same issue and they said that sped their systems up. Good luck.

Dave_Williams

We also have experienced the same exact thing you're describing. We have our Orion server and SQL server separated so not really sure what the issue is despite Solarwinds recommendations that placing them on separate servers would increase performance. We are also running in an enterprise environment with hundreds of servers, routers, and switches so not sure if we're overloading the poller somehow. We have the maximum amount of RAM in both servers but still the web interface is moving at a snails pace. We are however planning an upgrade to a 64-bit OS with at least 16 Gb of RAM so hopefully the upgraded OS and additional RAM will make a difference.

netlogix

you might also want to limit the amount of RAM SQL takes. SQL will take RAM till it starves the rest of the server (Open SQL Managment tools, properties on server, Memory, set MAX - the higher it is, the less disk time, but more it starves other apps, you need to find a good balance)

stephen.black

We too are having issues of this nature and have been for a very long time. We thrown unrealistic amounts of hardware at our console install, offloaded SQL to a dedicated box, and still we have terrible web console performance. Recently we used Wireshark and identified Zero Time Window issues (forgive me is the term is not correct, network guys found it). I was told this points to issues with the TCP stack.

Dave_Williams

Ok not sure if I'm in the right place or not but I'm in the properties of the server like you stated and in the memory section but the settings seem way off. The server only has 4 Gb of memory but the max is set to 2147483647 which is in Mb. The minimum is set to 0 and is set to use AWE to allocate memory. I'm no SQL master and don't want to change these unless recommended to do so otherwise. Just don't want to slow it down anymore that what it already is. Also our SQL database is on a server that we normally use for a data capture machine so that would be the only thing in my mind that it would be competing for memory for other that the normal Windows goings on.

netlogix

That is the spot - SQL is configured right out of the box to consume as much memory as it can (2147483647 - 2 PB, man I wish I could afford servers with that much RAM!), but I have found this to cause issues by starving the underlying OS. I would suggest you set the RAM to 3*1024=3072 to leave 1gb for the OS and only use that server for SQL (I don't know what you mean by "data capture", but if that is consuming memory or disk time; it is taking it from SQL, that could be the problem - of course if it runs for 5 minutes once a day, and you don't care if there is a slow down at that time, then it doesn't matter). I use 2008 R2 Core because that keeps people from TS-ing into the server and starting a bunch of tools they could/should be using from their desktop to manage the server remotely.

Deltona

Those days were 2GB of RAM was alot has long passed and gone. You need much more than 2GB considering this is a monitoring system and also considering that SQL is installed and running on the same server. These two roles will never idle on the server.

You'll need a minimum of 4GB for a test where everything is running smoothly. Note that if your operating system is not 64bit then you won't be able to address/use more than 3.5GB of overall system memory.

More important still is the type of disks used on that server. Since Orion is a web based application, you'll need storage that is capable of supplying the IOPs demands that a web server requires (rule of thumb) and the even higher demands that a SQL server has in terms of IOPs (also rule of thumb).

Number of disks and RAID type is key to a well performing web application/SQL server. I presume you are using RAID for the disks, if so, RAID 1 and RAID 5 are generally considered as none web/SQL-friendly RAID types. When you invest in Orion as your NMS system, you'll need RAID 10 (RAID 1+0) to have everything running smooth. SQL would preferrably be running on a dedicated server.

With regards to SQL and memory, take netlogixs' advice in limiting memory usage. A good place to start would be to limit SQL memory to 70% of system memory.

So if you have 3GB of memory in the system you should limit SQL to use 2150MB. This leaves 920MB or so of memory for the OS, the application and the web server - and that's not an awful lot! You could limit SQL memory usage to below 70% but then SQL would suffer and you'll notice performance issues with slow web access, too.