High CPU Load by scheduler
Here tree sreen shots (details of the problem):
scheduler2a and b.jpg with started scheduler
scheduler2c.jpg after stopping scheduler.
By the looks of screenshot scheduler2a it would appear that Acronis and Windows Update (Local Security Authority Process) is consuming a like amount of resources. Go to Settings, Update and Security, Advanced options, Choose how updates are delivered, and switch off Updates from more than one place.
See if that solves the issue.
Dear Enchantech,
update policy is as you suggested.
Local Security Authority Process (lsass.exe) is also consuming al lot of CPU. But after stop of scheduler2.exe the process lsass.exe consumes only a small amount of CPU.
>> Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.[1] It also writes to the Windows Security Log. ( https://en.wikipedia.org/wiki/Local_Security_Authority_Subsystem_Service ) <<
>> Post #9: (1) Yes guitoo, on my system the CPU load is also caused by the two processes
"schedul2.exe" and "lsass.exe". <<
The symtoms are the same as in post # 18. I own two identical notebooks with SSD and Windows 10 Pro (Fujitsu AH530). Both have this issue. My 2 PC with SSD and Windows 10 Pro dont have this issue. It seems to be hardware dependent.
Post # 31 and # 38 (by you dear Enchantech) are also interesting.
As i am only a customer an not a devoloper i hope acronis team will fix the problem. Think they have enough of informations.
Enchantech, thank you for your help.
You will need to contact support with your issue for investigation.
Dear Enchantech
opened Case 02879431.
Happy new year 2017!! :-)
The reply I got from my submitted case is:
"I would like to inform you that it is a known issue in Acronis True Image 2017. Our development team is working on this issue.
As of now, there is no ETA regarding this issue. I will keep this case open once the issue is fixed I will let you know."
Posters,
Another user on a different thread found a solution to high CPU load. Although this user experienced the problem in a slightly different set of circumstances his solution may well work for you too. It certainly won't hurt to try it, have a look at post number 5 in the link below:
Dear Enchantech,
thanks for your investigation. Nice idea. Enabled autostart of schedule 2 and disabled Intel Management Interface Engine Interface (post #5 named it Intel Management Interface) and reboot. CPU load of 50%, after stop of schedule 2 all OK. Nice attempt but did not work.
Thanks a lot and happy new year.
Thanks for posting back your results.
Is CPU usage high all the time or only during backups?
What type of backup scheme are you using as well and how often does it run?
During local backups, my CPU goes through the roof (sometimes hits 90%), but is always low when not backing up. CPU remains pretty normal when backing up across the network to my NAS so believe the high data transfer rate is spiking usage on my local backups.
I didn't read the entire post, but even if you tried removing the app before, try a repair install using the original insaller (make sure you have the latest from your account). When you run it, make sure to right click and "run as administrator", even if logged in as admin already - this is the only way to get full admin privileges for the installer of any application. Then, you should see an option to remove or repair - do the repair and reboot before launching the app and see if CPU is high or not.
Also, when you're seeing the high CPU, are you logged in with an admin account or a regular, non-admin user account?
The CPU usage is !! allways !! high. This issue is known. A case is opened.
Seems to be a hardware dependent issue because my other 3 systems with same software configuration but different hardware are OK.
Try the repair install - can't hurt, might help.
What's unique with the hardware where the issue is occurring - CPU type in particular, hard drive (what type/make/model) and just curious of the model if it's an OEM like a Dell, HP, Toshiba, Lenovo, etc.
I fixed the problem.
Scheduler is a service, started automatically with account "local system" in german: "Lokales Systemkonto". All of my 3 pc and 2 notebooks have the same configuration, only the hardware is different. But only the two identical (Fujitsu AH530) notebooks have this issue.
On my notebooks I changed the account for service scheduler2 to an administrativ account and it works. No high CPU load. It is obviously a problem of the authorisation of the service. Don't ask me why the other machines (pc NOT notebook) are OK with the other (normal) configuration and why I have only trouble with my notebooks.
A new installation will not change the sw configuration. Only this: scheduler will start with account system (Lokales Systemkonto) again.
I am waiting for Acronis solving the case 02879431. I have updated my case history to inform Acronis about my remedy action.
Glad to hear you discovered the problem. May I ask, when you installed the True Image application did you do so using an Administrator account? If not then that would explain the issue. Installing using an Admin account is required for correct operation of True Image.
I allways install my software with a non administrativ account. When promted i change to the admin account. 3 times ist has worked correct. In 2 of 5 cases it came to the issue. Hence i see no connection.
You may like to read post: 127825: Cannot mount password-protected backup as non-admin user for which I opened a support case and received the response shown in post #12 of that topic.
I checked with my resources and I would like to inform you that
we need to have admin privileges for any actions using Acronis True Image application.
Thank you for info. Nice, sometimes it works sometimes not. What astonisching software.
Post #64 is only a temporary fix. The problem is acronis monitor. After a backup CPU utilisation is high again. If you kill the true image monitor task the CPU utilisation in normal again. This has beeen mentioned before in an other post. Acronis know this (posted earlier). Hope they fix this issue.
Hello Everyone,
The ticket about high CPU usage caused by Acronis Scheduler and True Image Monitor is still opened. Development Team is still investigating it.
On a side note, if anyone observes that behavior with the build 6116 or newer ("Acronis True Image 2017 New Generation"), please let us know. We had an opportunity to check if the problem persisted after updating to the build 6116 in a few different environments, and it did not. The new version seems to not having that issue.
Fixes introduced in the build 6116 will become available to users of Acronis True Image 2017 (perpetual license) approximately in a month.
Regards,
Slava
Hi all, today I updated Acronis True Image 2017 to the latest build 8029.
As announced by the Acronis support team the issue now seems to be solved, i.e. my support ticket (Case ID 02813315) will be closed.
Regards, Guntram.
Guntram, thank you for your feedback, glad to hear that this issue is resolved with the latest build 8029.
I can confirm that build 8029 seems to have solved the problem of continuous high CPU usage by the Acronis Scheduler service.
I have 4 PC's with TI 2017. All exhibited the problem, even though the installations varied - some in Admin accounts, others in Standard accounts, some with TI2015 previously installed, others not. In every case, high CPU usage could be temporarily prevented by stopping, then restarting the Acronis Scheduler service. It seems that the runaway Scheduler service would be triggered again any time the PC was rebooted.
After a week of using 8029 on 3 PC's, I have not seen Acronis Scheduler continuously taking 10 -20% of the CPU cycles. Thank you!
barotropic, welcome to these user forums, and thank you for your confirmation that the high CPU usage is fixed by the latest build 8029 - it is always good to have positive feedback on these issues.