Follow PFE on Facebook
It’s really surprising how many people really don’t. They might think they do… but they really don’t… or they don’t take a full inventory of the possibilities. Yes, most of us are relatively good at making some attempt to push scheduled activities off to the evening to prevent impacting the user experience… but can you tell me what your server should be doing right NOW? I’d bet no… at least not without a significant amount of research.
Lets go through the possibilities. At any moment in time, your server could be…
…serving user requests during peak usage hours. …running full crawls daily. …running incremental crawls every 30 minutes. …importing user profiles daily. …doing usage analysis processing daily. …running your STSADM backup scripts daily.
Or at least that’s what you think it could be doing… but have you tried to make sure that it’s not trying to do all of these things at the same time? Further, have you considered that there are probably other people in your company that are also doing their jobs on your server farm?
…your platforms team is deploying system updates once a week (resulting in unexpected server reboots) …your DBA is doing SQL backups and running maintenance jobs daily (resulting in significant disk IO) …your Antivirus team is running full scans of your server once a week (resulting in significant disk and processor IO) …your Backup team is running server backups daily (resulting in significant disk and network IO) …your Google appliance is indexing every 6 hours, or 4 times a day (forcing every page, file, and link in your entire farm to be loaded, compiled, and rendered).
So, overall, your system utilization looks something like this:
Notice how many activities are happening at the same time? Backups, profile imports, indexing… all happening at the same time. We (the SharePoint administrators) have done a good job pushing things outside of peak usage (except our incremental crawls)… but we’ve unintentionally set several things to happen at midnight, and we haven’t coordinated our activities with the things that other groups may be doing. Also, because of the order of events we’ve chosen information could either be out of date or could cause significant performance impacts.
A part of this is to understand what we really need to accomplish.
For demonstration purposes, lets assume we’ve discussed and coordinated our schedules with the various groups (platforms, SQL, AV) and are going to assume the following:
Taking these things into consideration, we have the following schedule:
So, now our calendar looks like this:
This is better because we’re not doing any work unnecessarily, and we have some gaps in time that allow some processes to unexpectedly go beyond their planned times. This also ensures that we’re backing up before any significant activities happen that could impact the server or content, such as antivirus scans (which risk corrupting a file if the file must be cleaned).
It’s also better because now I know EXACTLY what my server is doing at 10:00pm. :)
If you’re using virtualization, be sure to also look into what the other virtual machines in your environment are doing. Remember that you are impacted by whatever the other VMs on the same physical host as you are doing. If they’re using all of the disk capacity for example, your processes will take longer and your timelines may need to change. More virtual machines does NOT MEAN more computing resources!!!