SQL Server 2005 64-bit 100% CPU

  • Continuing the topic http://www.sqlservercentral.com/Forums/Topic1352495-377-1.aspx

    Hey Guys,

    I keep having the same problem, but now I have some useful informations, see below:

    First, we have changed the MAX DEGREE OF PARALLELISM (http://msdn.microsoft.com/en-us/library/ms181007(v=sql.105).aspx) parameter from 0 to 4, but we have some problems in maintenance then we return to 0, but when this parameter was on 4, we had the same CPU problema.

    Second, we find the "auto update statistics asynchronously" option that was on default "false", we change to "true", because we had the suspect that when a lot of queries are using the same tables, the SQL was unable to update the statistics, but 1 hour after change this parameter, we had the same CPU problem.

    But, when we was looking the SQL, we find the same query a lot of times, this query is used multiple times by a lot of threads from the Weblogic server in the same time, like 150 executions simultaneously on the same table.

    So, we start to question about the OUTPUT and INSERTED impact.

    UPDATE nextEntryIn SET STATUS = @P1 , DATE_TIME_PROCESSING = getDate()

    OUTPUT INSERTED.COD_QUEUE_IN, INSERTED.PRIORITY, .... few more fields

    FROM (SELECT TOP 5 COD_QUEUE_IN, PRIORITY, .... the same few more fields

    FROM QUEUE_IN

    WHERE STATUS = @P2 AND CONSUMER = @P3 AND PRIORITY = @P4

    ORDER BY COD_QUEUE_IN ASC)

    AS nextEntryIn

    Again, when the CPU goes high, we make the rebuild on this tables and the data of companies table.

    Thanks for any help.

  • Start by reading chapter 3 of http://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/

    Don't guess as to causes and fixes. Identify what queries are using a lot of CPU and tune those specifically. If you change settings at random, you'll never know what the cause of the problem was.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply