2

So the server is slow:

Roll back to the previous known working build - Success? Code problem - Fail? Go on.

Ping ip address - Success? maybe a DNS problem, go on. - Fail? Server or connection problem, go on.

Ping and tracert your domain.com from inside your network - previous success - fail: DNS problem - success? go on. - previous fail and: - Fail? Go on, could be you or network. - Success? Go on.

Try it from outside your network (http://centralops.net/co/) - Fail? The server's network connection sucks. - Success? If inside network was fail, your network sucks.

Check the server load: CPU/RAM usage. Is it overloaded? - Yes. Who's the culprit? Kill some processes/reboot. - No? Go on.

what other steps should i add?

1
  • This probably should be a community wiki.
    – Zoredache
    Mar 11, 2010 at 23:45

1 Answer 1

1

I think the first thing on your 'flow chart' should be creating a baseline of the servers performance. If you don't have a baseline to do comparisons, how do you know it's slow?

Configure your server to collect server and network performance data. Slow servers can be anything from a sudden user surge, to a malfunction raid array. Sometimes slow down are only for short periods, thus effecting some users. Once you've logged into to check the problem that condition may well have cleared itself up (temporary memory exhaustion for instance).

This reflexive fault finding will be okay to solve major problems such a degraded raid arrays, but not intermittent or short lived problems.

If you have good logging then you can probably solve the problem before it becomes an issue.

Preventative maintenance is the key with excellent logging will make you feel better!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .