Ultimately, you need to know what the server is doing when the problem is apparent, and what the server is doing when all is OK.
Other than saying the network is going slow, you don't really give any clues as to how the server is responding.
When you say that the network is going slow, do you mean that the client application is running slowly, talking to the server, or do you really mean that packet responses are taking a long time?
My action plan would be:
- Confirm that the server's hardware is OK. If you have the ProLiant Support Pack (PSP) installed, browse to https://yourservername:2381 (you have this installed, right?). Logon using an account with admin privs and check the state of your hardware
- Check the configuration of your network card(s). See what sort of round-trip latency you have between server/client (from the client, run ping -t servername).
- Check the event logs (particularly the system log) - run eventvwr.exe
- Check the free-space on your drives. Find out where your paging file(s) are, and how big they are. Consider de-fragmenting your drives.
- Use performance monitor to examine:
a) Physical disk - average disk queue length (want this to be <= 2)
b) Physical disk - % disk time (don't want this to be constantly > 80%)
c) Processor - % processor time (don't want this to be constantly > 80%)
d) Network interface - bytes sent/sec
e) Network interface - bytes recieved/sec
f) Memory - page reads/sec
6) Finally, a bit lower level, but Systems Internals' (now Microsoft's) Process Monitor and Process Explorer tools are fantastic at providing an insight into what's actuall happening on a server
So, the server is otherwise healthy and responding OK (can remote desktop to it and "use it"). The reason for stressing this point is that Windows Server doesn't handle kernel resource starvation too well. Linux starts killing processes when the kernel is threatened, but MS haven't cottoned onto this idea yet. When kernel resources are maxed out (non-paged pools, Etc), Windows servers can just stop responding... until something frees up a kernel memory resource. Not having a sufficiently large paging file (or files) can expedite resource starvation on busy servers. My next steps would be:
- Check SQL counters in perfmon (as Hennes suggests)
- See how SQL is responding on the server when you are experiencing problems (can you perform basic queries from SQL Management studio?)
- Check the configuration of your SQL server (memory and CPU parameters)