Performance Considerations: Separate DB's?

Question

I am running the latest release of Solarwinds with the following additional modules:

* SAM
* NCM
* NTA

I've noticed that performance can be slow at times.  I have all DB's running on the same server.  Should I use an additional DB for NTA or Logs to increase performance?

swright · Answer

This was very helpful!  I have just added my DB to DPA and will await results.  Thank you for your response!

jm_sysadmin · Answer

This is a harder question than it sounds. The answer starts with "It depends.. " which is hard to hear but truthful.
Lets start with what I don't know:
-What Orion products are you running? I see SAM, NCM and NTA, but if you have those three you likely have NPM. If so, what version of syslog capture are you running, the old school or the newer Log Analyzer version? Anything else missing integrated into Orion? 
-How many nodes and elements are you watching? NPM checking the total number of elements with Orion diagnostics (solarwinds.com) 
-Have you altered the polling intervals or retention settings? Configure polling statistics intervals in the SolarWinds platform 
-What types of slowness do you see? Is it everything everywhere? Does polling complete on schedule? Is it just certain views? Can we narrow it down to particular widgets?

You say performance is slow, have you identified the bottlenecks? I use DPA ( Database Management Software | SolarWinds ) to assist tracking down what causes my slowness. I start with the basics, CPU, Memory and Disk. While SQL will use every bit of Ram you give it over time, the AppInsight SAM template will get you info on what's happening there. Disk IOPs can be important too. If virtualized, is there contention for those read and writes or other resources?

So enough abstract. In my install, I do not need to break out any of the DBs to other SQL servers or instances. I simply don't send enough work to them to make it matter. DPA has helped me find that most of my "slow" is from SWQL that I wrote for custom dashboards, reports, and a few alerts that aren't great. That said, I have in the last few years adjusted my SQL server resources, specifically around RAM. newer SQL allow a lot more work to happen in memory. I am also running in VMware, and the hosts that run my SQL are designed for the workloads specifically, all the way down to optimizing disk access where I have seen 100,000's of IOPs and no contention. If you can't add resources, but know they are an issue, then yah move to a new instance.

I wish there was an easy answer but performance is all about what you need to do and what you have available to you to get it done. Its hard to give a clear recommendation.