Taking Action: Executing a Command
Download this article in PDF format
When server downtime must be kept to a minimum and taking
preventive action is not possible, quick and responsive problem resolution is
key to shortening downtime. Restarting a
server or process can get things going again, but it can also mask the problem
and increase downtime.
How does one decide which to do: restart the server - read
reboot - or restart the process generating the error?
Take for example a web server that is generally error free
and bears a moderate load of traffic. In
the case of an outright failure to connect to this web server – connections are
actively refused - it is probably best to alert via email to diagnose the
problem first before restarting the server.
This is especially true in a load-balancing situation where you have
other servers that can pick-up the load for a short period of time. When only one server is involved, it may be
best to simply restart the web server software.
For Windows Operating Systems, e.g. Windows 2000 and Windows Server
2003, one can quickly restart IIS with the command “iisreset.exe” which is
located in the \windows\system32 directory.
In the case of an error message or HTTP status code that
denotes an error, restarting the web server software or restarting the server
may not help at all. If the error is
caused by faulty web application code, or a problem with the database, the
error could reappear as soon as the web server is back up and running.
To monitor for these types of situations, one should put in
place a two-pronged strategy. First,
monitor for connectivity loss and setup actions to either restart the web
server software process or restart the server completely. Second, monitor for error conditions and
alert the appropriate people who can investigate the problem and find a
permanent solution; restarting the process or server is simply overkill.
|
