none
system idle processes high

    Question

  • performance on our server 2003 r2 has declined dramatically recently. in looking further, i note that cpu usage is 60-80% with no users accessing the server, and system idle processes in the 40-60 range. where should i look further?

    thx
    Tuesday, December 29, 2009 10:59 PM

Answers

  • Hi,

    Thanks for the post.

    When a computer or a processor within the computer is idle it will have a high System Idle process in the CPU column, often in the 50's to 90's. This is completely normal for a computer as it waits for something to do.

    Hope this helps.

    Miles

    Wednesday, December 30, 2009 1:48 AM
    Moderator
  • Hi ,

    I agree with miles , these are system processes and there is no user mode applicaiton / code running under them.
    So you could be safe to ignore the system processes and identify only cpu utilization part.

    You can use sysinternals utilities such as process exploer to identify which process is consuming more cpu and you can walk through the stack to identify the handle / thread which is responsible for the cause.

    You could also test the behavior in safe mode just to make sure none of the microsoft components are causing the problem.
    Wednesday, December 30, 2009 2:34 AM
    Moderator

All replies

  • Hi,

    Thanks for the post.

    When a computer or a processor within the computer is idle it will have a high System Idle process in the CPU column, often in the 50's to 90's. This is completely normal for a computer as it waits for something to do.

    Hope this helps.

    Miles

    Wednesday, December 30, 2009 1:48 AM
    Moderator
  • Hi ,

    I agree with miles , these are system processes and there is no user mode applicaiton / code running under them.
    So you could be safe to ignore the system processes and identify only cpu utilization part.

    You can use sysinternals utilities such as process exploer to identify which process is consuming more cpu and you can walk through the stack to identify the handle / thread which is responsible for the cause.

    You could also test the behavior in safe mode just to make sure none of the microsoft components are causing the problem.
    Wednesday, December 30, 2009 2:34 AM
    Moderator