Início / dba / Perguntas / 54463
Accepted
Greg Bala
Asked: 2013-12-05 13:03:53 +0800 CST

Pico de CPU do SQL Server 2012 devido ao LinkedServer - como encontrar a consulta incorreta?

  • 772

Como parte de outra pergunta ( problemas de desempenho do SQL Server 2012 (talvez devido ao servidor vinculado) ), identifiquei um pico de CPU diretamente relacionado a um pico de Bytes recebidos, o que me leva a acreditar que é provável devido ao servidor de link .

O AMBIENTE

2 servidores, um servidor acessa um banco de dados no primeiro por meio de um servidor vinculado, para um bom diagrama, consulte os problemas de desempenho do SQL Server 2012 (talvez devido ao servidor vinculado)

insira a descrição da imagem aqui insira a descrição da imagem aqui Pico de CPU diretamente relacionado ao pico de bytes recebidos

PERGUNTA Como descobrir quais consultas podem estar causando isso?

TIPOS DE PERGUNTAS QUE REALIZAMOS

Passei por todos os nossos procedimentos armazenados e eles estão otimizados. Aqui estão os tipos de acesso ao servidor vinculado que fazemos:

selecione um valor da tabela remota

select @userid = userid from FBGC.FBGCommon.dbo.players where playerid = @playerid

execute o procedimento armazenado que retorna o conjunto de resultados de no máximo algumas centenas de linhas

exec FBGC.Fbgcommon.dbo.qPlayersFriends @PlayerID

executar procedimento armazenado que retorna um valor

exec @HasEnoughCredits = FBGC.FBGCommon.dbo.qDoesPlayerHaveEnoughCredits @PlayerID, @Cost

exclua algumas linhas da tabela de remoção

delete from FBGC.FBGCommon.dbo.InactivePlayersToBeWarned where PlayerID = @AccountOwnerPlayerID

Atualize uma linha na tabela remota ou adicione uma linha à tabela remota

update FBGC.FBGCommon.dbo.users set XP = XP + @XPForTitle where userid = @userid
insert into FBGC.FBGCommon.dbo.UserXPHistory (userid, time, XPReceived, XPFromTypeID, XPFromRealmID) values (@UserID, GETDATE(), @XPForTitle, 1, @ThisRealmID)

Acredito que tudo isso esteja otimizado, mas parece que estamos juntando tabelas no servidor vinculado!

Algumas estatísticas de espera interessantes que não sei como interpretar. Executei uma consulta em http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/

Eu recebo isso DURANTE o pico de CPU: insira a descrição da imagem aqui

Eu recebo isso quando não há pico de CPU: insira a descrição da imagem aqui

Esses tempos de espera estão no servidor com DB2, o servidor SQL 2012 que acessa um banco de dados remoto em outro servidor executando o sql server 2008 (para o diagrama, consulte problemas de desempenho do SQL Server 2012 (talvez devido ao servidor vinculado)

Reiniciando a ajuda do SQL Server - sem pico de CPU por um período de tempo significativo.

Também descobrimos que reiniciar o SQL Server ajuda - podemos obter picos intermitentes por horas, muitas vezes por hora e, após a reinicialização, nenhum pico por uma hora ou mais.

Explorador de processos

Conforme sugerido por @EdwardDortland, usei o Process Explorer para ver qual thread está consumindo mais CPU durante a lentidão

infelizmente, nenhum thread único aparece como o principal culpado - durante picos de CPU, simplesmente todos os threads consomem mais CPU. embora eu esteja vendo muito mais tópicos destacados em vermelho (significando excluídos) durante o pico da CPU - não tenho certeza de como interpretar isso.

Threads antes do pico da CPU insira a descrição da imagem aqui

Threads durante o pico da CPU insira a descrição da imagem aqui

sql-server sql-server-2012

2 respostas

  1. Para responder à pergunta: Como localizar a consulta incorreta:

    Como os picos no gráfico que você postou duram vários minutos, você tem bastante tempo para usar o seguinte método:

    Baixe o explorador de processos sysinternals

    1. inicie o explorador de processos e localize o processo do SQL Server.
    2. clique com o botão direito e selecione propriedades
    3. olhe a aba do tópico.
    4. Classifique na coluna da CPU e observe a ID do encadeamento (TID) que está consumindo mais CPU.

    Use esta consulta e procure a consulta que está sendo executada atualmente por esse encadeamento:

    SELECT r.session_id, st.text, qp.query_plan
FROM sys.dm_os_threads AS ot
JOIN sys.dm_os_tasks AS t
ON t.worker_address = ot.worker_address
JOIN sys.dm_exec_requests AS r
ON t.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) AS qp
WHERE os_thread_id = <thread id>
    • 3
  2. Best Answer

    Como descobri o motivo dos problemas, gostaria de compartilhá-lo, caso alguém esteja enfrentando uma situação semelhante.

    O motivo do meu problema não era o servidor vinculado, mas simplesmente a contenção de recursos - simplesmente não havia memória suficiente para o SQL Server com esses bancos de dados!

    ENTÃO - se você tiver sintomas semelhantes, pode ser simplesmente memória.

    A razão pela qual isso não era óbvio para nós é porque havia muita memória restante no servidor, porque a versão errada (32 bits) do SQL Server foi instalada - simplesmente não estava usando mais memória porque não podia

    Para uma ótima maneira de verificar a pressão da memória, consulte os comentários nesta questão https://dba.stackexchange.com/questions/55028/sql-server-2012-sp1-cu7-much-slower-than-sql-server-2008 - obrigado Paul White e outros por sua percepção!

    • 1

relate perguntas