SBSMonitoring causing sluggishness?

Monitoring is putting things in a sql server database, so it's normal it takes resources away.  
And if that monitoring database is in bad shape you can loose extra performance.

You don't need monitoring software. You have an I/O bottleneck. Specifically your apps are waiting for the disks to give them the data that they asked for.

The solution is one of two .
1) Minimize the amount of I/O that has to be done.  (Optimize queries, do less work, add some RAM for a little more buffering, change RAID level to RAID1 or RAID10 if you haven't done so, but RAM problems will show up elsewhere, so you probably would have noticed not enough RAM symptoms.

2) Throw more disk drives at the problem.  A HDD can only do so many things at a time. You are asking too much of them, so add more disks. Or add faster disks  (like SSDs). Or change to a more efficient RAID level, so each I/O can get done faster.

Specifically what is your storage config?  The more info the better, but pretty cut & dry. if you aren't going to redo some of your SQL databases to make them more efficient, plan to spend money on your storage config.

yep, it's definitely the disk IO and queue length. The screenshot cuts off the bottom, but at first glance it looks like your G: drive is the problem. I'd suggest turning this monitoring stuff off, and just use resource monitor, or perfmon to look at the disks. Once you find the disk that is the bottleneck, you can see what is writing so much. You may be able to just move things around or you may need an ssd or raid0 or something.

Hi,

What version of SQL?

There are some Dynamic Management Views (DMVs) on the newer versions that can give things like average read and write times per database file, which can point to which disk system has the bottleneck.

Things you can do:
Check that major database files are not on c: drive. (or a partition that is on the same disk as the system partition.

HTH
  David

Aaron - You said "Once you find the disk that is the bottleneck, you can see what is writing so much." How do I use perfmon to identify the disk that is the bottleneck? And, once it is identified, how do I see what is writing the most? Thanks for the input.

Perfmon lets you select the disk(s) you want to use.  Look at queue depth per drive.

Yeah, like he said ;)

Hi,

http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

Like the url says, a tutorial for using perfmon to look at SQL performance.

Regards
  David

I think sbs 2008 has resource monitor, which is way easier to see this stuff (processes, disk, queue) than getting into perfmon. If so, use that, but I might be wrong and it's not included until a later version.

http://www.techrepublic.com/blog/datacenter/use-resource-monitor-to-monitor-storage-performance/4233

Sorry for not catching this question earlier... but on an SBS 2008 you generally need to limit the amount of resources that Monitoring's SQL process uses.  See how to do that here:
http://www.thirdtier.net/2009/08/setting-the-maximum-memory-usage-on-sbsmonitoring/

Jeff
TechSoEasy

all the monitoring is going to do is verify what I posted ... You have an I/O bottleneck.
Either add more disks to handle the load, or give it less to do.  Since giving it less to do is rarely an option, then just save yourself some time and go shopping for some more disks.

@dlethe:   Monitoring is already something that is enabled on a Small Business Server.  It's the Monitoring Service itself which needs to be throttled.

Usually, the WSUS SQL process needs the same treatment.

My guess is that perhaps you have never worked with an SBS?

Jeff
TechSoEasy

Jeff,

Thanks for the link to the instructions to limit the resources that are used by Monitoring. I wasn't able to follow those instructions because I don't have SQL Server Management Studio Express in Microsoft SQL Server 2005.  Here is a screen snip of the programs from the Start button:


Also, what is the WSUS SQL process and could you tell me how I could give it "the same treatment"? Thanks.

thanks.