#1
|
|||
|
|||
Workaround for 100% CPU usage by sdbackupbytime
First, I want to mention that I've used SuperDuper! for years and consider it a great product. I'm currently using SuperDuper! 3.2.4 (v 118) on macOS High Sierra.
This morning I awoke to find SuperDuper!'s sdbackupbytime process using 100% of CPU time. After quitting the process via Activity Monitor or restarting the computer, the process restarts and resumes using 100% of the CPU. (Well, 100% of one core, anyway.) This appears to be due to a bug in SuperDuper! when a backup is scheduled to start during the hour after the switch to Daylight Savings Time. In my case, I had a backup scheduled to start at 2:00 am on Sunday March 10, which is the exact time that the DST switch occurs. (Interestingly, although the scheduled time was 2:00 am, the time in the description of the backup was "Every Sunday at 3:00 am…". That sort of makes sense because 2:00 am doesn't really exist; DST causes the time to skip from 1:59:59 to 3:00:00.) The workaround is to change the schedule so the backup starts before 2:00 am or after 3:00 am. Then all is well. Setting it to start at 2:00 am, 2:05 am, or 2:55 am triggers the problem. |
#2
|
||||
|
||||
This is happening in v118? I'd fixed the problem in October, so I'm rather surprised it would be back.
I'll take a look - thanks for the report.
__________________
--Dave Nanian |
#3
|
|||
|
|||
Yes, v 118.
I emailed details to support@shirt-pocket.com, including spindumps, etc. if you need them. |
#4
|
||||
|
||||
Thanks. It's a slightly awkward time to have this happen, because I'm out of the office for another week, but at least we have a workaround and it only happens to people whose backups land in that hour.
__________________
--Dave Nanian |
#5
|
|||
|
|||
I noticed high memory usage of sdbackupbytime today. I forced quit. It reappeared automatically and started using a lot of memory again.
|
#6
|
||||
|
||||
Change the backup time so it's not in the 2-3am range (eg use 3:05).
__________________
--Dave Nanian |
#7
|
|||
|
|||
Me Too
this is happening for me, but I don't currently have ANY scheduled backups.
??? perhaps this will go away once we've traveled into the future on Sunday? I'm running SD 118 and Sierra 10.12.6 Keeping Activity Monitor open to Kill sdbackup like a cockroach... |
#8
|
|||
|
|||
Me Too
I was finally able to keep the sdbackupbytime cockroach under the fridge by deleting all my past scheduled backups from the library and restarting my machine.
Lost 3 days of computer usability to this runaway memory hog process. Had started to price new systems... I blame Ben Franklin and his daylight "Savings" concept... |
#9
|
||||
|
||||
I don't quite know what "past scheduled backups" means here: did you have actual schedules? sdbackupbytime shouldn't be running if there aren't any schedules.
Anyway, apologies for the problem: a source code control issue allowed a problem I'd fixed in 3.2.3 come back in 3.2.4 (still don't quite know how it happened, frankly). We'll have it fixed in the next update, for good. (I wasn't able to get a fix out earlier due to being on vacation...)
__________________
--Dave Nanian |
#10
|
|||
|
|||
They were old schedules, probably created when I was running 3.2.3 (or older...) They were not active schedules and probably referred to external volumes that no longer exist.
Hope your vacation was relaxing and exotic, hope you had an appropriate beverage in hand while checking the support forums. |
#11
|
||||
|
||||
Had fun skiing, thanks. Cut short, unfortunately, due to a death in the family (Dad)...so back now.
__________________
--Dave Nanian |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|