Would rebooting the server in a schedule be good idea for performance?

I am wondering if rebooting a server in a schedule would be good idea for performance.

Let's say we want to reboot the server at 02:00 AM per 2 nights.

The server here is Windows Server 2008 R2. Mainly, SQL Server and IIS 7.5 (nearly 15 apps running) are running under this server. Server has 4GB memory.

Solution 1:

While I would agree that there is nothing wrong with rebooting the box, per se, based on your comment that the SQL Server Agent is stopping I would advise some additional root cause analysis. Services don't typically just stop, and the SQL Server Agent services hasn't acted that way in my experience, typically.

I think you'd do well, aside from rebooting, to examine the event logs and run a long-term performance counter log that you can analyze with Performance Analysis of Logs (PAL) to see if it "sees" anything wrong. You should try, if nothing else, to correlate the events associated with the SQL Agent stopping with other factors.

Solution 2:

If you are looking to reboot the computer to improve performance it probably means that eventually you are running into memory management issues.

Caching is Good

If anything, rebooting servers would hurt performance (and uptime of course) in a more ideal environment. One of the fundamentals of performance in computing is to take advantage of caching (having data available in fast memory). Each time you reboot, you blow away your cache. This is true of both SQL server and IIS. Although you might not have the ideal environment, the following should help guide you to a better option than rebooting the server on a schedule.

IIS Memory Leaks?

Now you mentioned that this is IIS 7.5. Although I find it depressing, so many web apps that run on IIS 7.5 have memory leaks that the defaults in IIS is to restart the APP every X minutes and shut it down if an APP pool is idle. The ideal is to fix the memory leaks -- but if you can't you might adjust these settings which include memory limits and timers. You can use perfmon to figure out which w3wp process is using the memory. It is a bit of a pain but you can tie it back the app pool with %systemroot%\system32\inetsrv\APPCMD list wps.

SQL Memory

Going back to caching, SQL will take what memory it can. You can limit this in the properties for SQL server. If you don't limit the memory and you are also running IIS on the box, these can start to battle for memory killing performance. This excellent article goes into this in detail: A Sysadmin's Guide to Microsoft SQL Memory.

Balance

Since you have both IIS and SQL on the same box, you will have to balance their memory usage. If you don't, you might get memory that is likely to be used again swapped out to disk -- which is a terrible place to be (There should be perfmon counters for swap activity). By using the IIS Recycle settings and the SQL Memory limits, you should be able to make this system stable. To balance this you might need more memory than 4GB. Also, if it is an option, I would strongly recommend putting SQL server on a dedicated machine -- it is going to make performance much better and greatly simplify things.

Solution 3:

I'm not a proponent of rebooting servers on a schedule, especially not as a means of resolving some underlying issue. If you need to reboot this server to resolve a performance issue then the better course of action is to find the cause of the issue and resolve it. Rebooting the server on a regular schedule is only obfuscating the underlying issue.

Solution 4:

If you've got significant memory leaks then sure, why not - otherwise reboot monthly with updates.

Solution 5:

If you really want to reboot the server on a schedule (because of the above-mentioned memory leaks or updates or any other reason) - why not look at a cluster solution? Put up another server in parallel, hook them up to a load balancer (even a simple one would do) and you can reboot them as much as you want without losing service up-time or worrying that the server won't boot at all and you'll be out.