-3

In my server I have a SQL process that consumes CPU (~10%) but no one is using the server. In query select * from master.dbo.sysprocesses order by cpu desc I see at least one suspect process:

spid: 9
kpid: 1432
waittime: 353
lastwaittype: SLEEP_TASK
cpu: 15890281
status: background
cmd: RESOURCE MONITOR

How can I discover and kill that process?

Improve this question
2
  • 2
    In a vacuum this means nothing. 10% of CPU? How many overall processors? Ordering by CPU won't help you if the server has been up for a while. Also there are processes that run in the background, constantly, depending on what is enabled on the server. If this is 10% of 100 CPUs, yeah that's a problem. If this is 10% of 2 CPUs, I'm not at all worries and wouldn't waste time. This needs more information added to the question.
    – Sean Gallardy - Mostly Retired
    Jul 14, 2019 at 17:23
  • The result of command 'select @@version' is Microsoft SQL Server 2014 (SP3-GDR) (KB4505218) - 12.0.6108.1 (X64) May 29 2019 20:05:27 Copyright (c) Microsoft Corporation Web Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor) I have 2 virtual processors. I think there is a problem because we can see this when no one is using the server.
    – Hugo
    Jul 14, 2019 at 19:50

1 Answer 1

Reset to default
4

In my server I have a SQL process that consumes CPU (~10%) but no one is using the server.

There are many background tasks that run, regardless of user activity inside of SQL Server. The key is to understand if 10% CPU is abnormal.

I have 2 virtual processors.

You have 2 processors, 10% cpu is not a problem. The system, idling, is probably going to use that just due to the low processor count. I honestly don't see a problem here.

I think there is a problem because we can see this when no one is using the server.

Again, this doesn't seem to be abnormal for the small environment. The background tasks in SQL Server along with OS tasks can easily make the system "idle" at 10% with 2 virtual processors.

I understand but we have other instances where this never happens. With this one, this does not always happen, for example if you do a restart, this is no longer true, but other times it stays that way.

We have no idea what the others instances look like, are they all 2-virtual cores? Same host? Same memory? Same workload pattern? Same databases? etc.

I'm all for getting to the bottom of things and figuring it out but honestly the pay-off just isn't worth it. I'm not saying you can' investigate further, I'm pointing out that this site would not be the best place for an ongoing triage of ~10% cpu on a 2-core virtual server which may or may not be all contained inside of SQL Server.

Improve this answer
2
  • Yes other instances are in same host, all the same except the databases. We have 4 instances but only one have this problem.
    – Hugo
    Jul 15, 2019 at 8:38
  • We noticed that in our daily backup job we were trying to backup a database that does not exist. We corrected that and now we no longer see the processor consumption. I do not know if it is related but the comment remains. Thank you for your opinions so far.
    – Hugo
    Jul 20, 2019 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.