CareerCup

- Check the event logs and system logs for anything suspicious
- Look at the thread states, how many are in blocked status, idle status. If any thread is in blocked status, then get the process dumps and see which thread is holding the resource and eventually making other thread to wait
- Cross check the memory pattern and see unused things are getting cleaned up regularly or not. if memory cleanup(GC in .NET) not happened then check in which GC cycle its been accumulated.

First step will be to check the logs.

In a java application on a unix box

1. Check application log files
2. Unix OS based functionality: top / iostats / tcpdump (isolate what it is doing), df (is the disk full)
3. generate an application level thread dump, examine which threads are stopped / waiting / deadlocked, (kill -3 <java process id>)

In a java application on a unix box

1. Check application log files
2. Unix OS based functionality: top / iostats / tcpdump (isolate what it is doing), df (is the disk full)
3. generate an application level thread dump, examine which threads are stopped / waiting / deadlocked, (kill -3 <java process id>)

Let me tell you, customer environment does not entertain you for debugging. You can ask to get logs or other data in a minimal way. Depending upon how mission critical situation is, customer might allow you to do left and right, but in general avoid going into depth at customer end. Just capture the steps customer has taken to reproduce the issue and request for any additional logs might be useful.