SQL Backup Pro 7 - SQBCoreservice.exe - Running at 97% CPU
SteveH
Posts: 1 New member
in SQL Backup
I am new to this tool and reviewing this on a production environment. I have noticed that when logging onto the GUI and server(s) are listed, it starts to retrieve backup history for these. SQBCOREservice.exe process on the server can use up to 98% CPU for several minutes which in turn impacts on the resource on the server available to other processes. I log off SQL Backup Pro 7, but the process still consumes resource.
I have checked various threads on the web, and it is suggested that this high cpu is caused by retrieval of backup history. Logging out does not notify the agent which continues to completion. The solution is to restart SCBCoreService.exe.
Under the circumstances I am reluctant to logon to the backup GUI during the working day. Is there a known fix\workaround to this issue?
Thanks!
I have checked various threads on the web, and it is suggested that this high cpu is caused by retrieval of backup history. Logging out does not notify the agent which continues to completion. The solution is to restart SCBCoreService.exe.
Under the circumstances I am reluctant to logon to the backup GUI during the working day. Is there a known fix\workaround to this issue?
Thanks!
Tagged:
Answers
The SQBCoreService.exe or the SQL Backup Agent service, controls all functionality of SQL Backup. It communicates with the SQL Backup GUI when the server is registered in the SQL server pane.
The SQBCoreService.exe will continue if there are backup and restore tasks in progress. The SQL Backup Agent service controls the communications with SQL Server when performing a backup or restore task and performs the actual backup and restore process, creating the VDI, compressing and (if configured) encrypting the backup data when performing a backup job or decrypting and uncompressing the backup data when performing a restore. So if you have a busy server with a lot of databases, performing backups throughout the day it will use a lot of processor resource.
There is not a fix for the problem as such, but there are steps you can take to help the performance. However there is not a solution that fits all, what might be good in one environment may not work in another. For example, the SQL server may not have sufficient free disk space locally to backup a large database, so a backup direct to a network share is the only option. So in paragraph 2 below, the advice is very much trial and error for your environment.
1. In regards to the SQL Backup GUI, do not keep large amount of backup history. Use the system stored procedure sp_delete_backuphistory. Once you have run sp_delete_backuphistory, enable the SQL Backup GUI File Management options to keep the history manageable by deleting older history. further reading on the options available here:
https://documentation.red-gate.com/sbu9/settings-and-options/file-management-options
2. The backup jobs themselves, review the number of threads used, the compression level configured, the frequency of the job and balance this against the importance of the database, the number of concurrent jobs can be factor. The backup location, do you backup to a local disk and copy to a network share or backup directly to a network share.
Do not use more threads than the number of processor cores. The maximum thread value is 32, do you have the number of processor to run 32 threads? Consider reducing the number of threads as required. Maybe a bad example, if you have a single quad core processor and attempt to perform using 32 threads, in my experience the job will run much slower compared to setting the thread value to 2 or 3 threads.
Compression level, the theory is the higher the compression level more CPU cycles this uses. Reduce the compression level to a lower value.
How often are you performing the backup. If performing a backup every 5 minutes, can you reduce this to every 15 minutes. How many jobs are running simultaneously, consider spreading the jobs, reducing the number that are concurrent.
Backing up to a local disk and then copying t a network share is less demanding on the resources compared to backup directly to a network share.
3. The workload of the server, are there too many databases for the server to cope with. Is the server on a Virtual machine that is not resourced correctly or the virtual machine host is running to many virtual machines.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com