2

Have a low specced server I've been troubleshooting (it is above MS's minimum specifications for SBS2011)

One of my next steps is disabling what I can of Sharepoint as it is not used.

Here are previous steps I took to recycle IIS Worker Processes, several of the processes I restricted were related to Sharepoint.

Recently (as I have got more performance from the server) I have seen the following more:

It seems Sharepoint is thrashing the HDD for some reason, how can I investigate more about this and where should I be looking to stop this?

I understand my IIS recycle rules may be causing this, but without those rules the IIS database held in RAM is so large the rest of the Server suffers far worse than the current scenrio.

These users are not using Sharepoint!

HaydnWVN
  • 415
  • 2
  • 8
  • 27
  • 1
    Have any of these answers helped you? The bounty expires today. – MDMarra Sep 18 '13 at 13:58
  • Sorry MD only caught the notifications today (and the bounty had expired). Will go through Snowburnt's suggestion when I have time (and next connected to the site). Will mark as correct if it solves the I/O. – HaydnWVN Sep 19 '13 at 13:46

5 Answers5

1

The SharePoint search service has extremely high IOPS requirements. If you're not using SharePoint on this server, you should uninstall/disable it. If you are using SharePoint, you should read some of the Microsoft documentation for best practices and hardware requirements.

Search Services has 4-digit IOPS requirements, if I remember correctly, which is nothing to sneeze at. In larger installs, it's quite common to have a server in the farm dedicated just to search indexing.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • This is SBS2011, I found very little information when looking to disable SharePoint. The majority of places say to not uninstall/disable it?! The poor Server only has SATA disks so I'm not surprised it's struggling! – HaydnWVN Sep 11 '13 at 13:14
  • 1
    Oh, yeah if this is SBS then I'm not sure. I missed that fact. SBS is so ugly for so many reasons :) – MDMarra Sep 11 '13 at 13:15
  • It seems IT were not consulted when someone from the old Management team chose this SBS 2011 server (ML350 G6) as an 'Email Solution' - for 3 users at a remote site. It's complete overkill, but also not man enough (spec wise) to run SBS2011 well and some 3rd party database software. Yet it's now left for IT to 'resolve' with ZERO budget! (Means I've spent months already trying to improve performance!) – HaydnWVN Sep 11 '13 at 13:40
  • 1
    Good luck! I hope someone with more SBS experience finds this to give you a better answer. – MDMarra Sep 11 '13 at 13:57
  • I'd kinda given up hope, anything over 6 months (and only 60 views) doesn't tend to get much attention! – HaydnWVN Sep 11 '13 at 14:11
1

I'd suggest disabling the search service.

Log into SharePoint central administration, go to application management, manage service applications, click on the search service.

You should be able to set the crawl schedule and crawl rules. Set it so that it never runs. Also you may have a crawl in progress, stop it.

After that go back to the manage service applications and stop the search service.

The search indexer will fill up your database server and hard drive with the index (it stores the index on the hard drive as well) if you're not planning for it or have it configured properly. Disabling the search indexer won't hurt anything if they're not using it.

Snowburnt
  • 775
  • 2
  • 5
  • 18
  • I'll attempt this, as previously commented I had stopped it from Services to find it auto-restarts as other services depend on it. – HaydnWVN Nov 20 '13 at 08:50
  • @HaydnWVN If you stop it in SharePoint it shouldn't start up again. In the services mmc you can look at the dependencies in the properties, there shouldn't be anything depending on search that you can't do without, especially if you're not using search. If you actually DISABLE it in services also, it won't start up even if has dependencies. – Snowburnt Nov 22 '13 at 15:26
  • Yeah but I don't want to 'break' anything... This is SBS after all! Will give it a try and report back! – HaydnWVN Nov 28 '13 at 16:17
0

Have you tried disabling the sharepoint search service? You should just be able to go into services, stop, then disable the service from startup.

Steve Butler
  • 1,016
  • 9
  • 19
0

Bearing in mind that I'm running SBS08, not SBS2011...

It's true that places tell you not to uninstall/disable it, but the usual reason given is that it will hamper your SBS upgrades. I suspect you're not going to upgrade SBS on that particular server.

So, what I would do, during scheduled maintenance, is:

  • Disable all sharepoint services.
  • Disable the MSSQL$SHAREPOINT service.
  • Test.

Of course, it's not that tightly integrated into SBS08. But if you have some downtime where you can try it and see if it breaks anything, it might be worth experimenting.

Katherine Villyard
  • 18,550
  • 4
  • 37
  • 59
  • Disabling SharePoint on SBS isn't a good idea as many other things seem to rely on it... – HaydnWVN Sep 20 '13 at 08:49
  • Yeah, like I said, I'm doing SBS08. The previous admin broke Sharepoint--accidentally--and it was down for over a year with no ill effects. I fixed it, but then ended up disabling it because no one was using it. It sounds like SBS11 uses it more heavily. – Katherine Villyard Sep 21 '13 at 17:21
  • Did you disable it using the method you outlined above? – HaydnWVN Nov 20 '13 at 08:51
  • Pretty much, although taking over a box where it was pre-broken and using the SBS tools without it was also a bit of a test. ;) Again, though, SBS08. So it didn't have an MSSQL$SHAREPOINT service. I'd moved WSUS off Windows Internal Database and SBS08 has MSSQL$SBSMONITORING, which I left up for the SBS tools. So you might have to leave the Sharepoint instance up. – Katherine Villyard Nov 20 '13 at 15:26
0

Same behaviour here. Based on previous comments, my solution was to change service execution time from minutes to three threshold hours at night. It stopped high disk usage and appears to be working.

ju4nj3
  • 3
  • 1