Unlocked 1Password mini tops "Apps Using Significant Energy" list on Yosemite
Hello,
I'm not entirely sure when this started, but at least I'm certain it never occurred with 1Password 4 on the Yosemite developer previews during the summer of 2014, when I was working without mains power every day.
Running 1Password 5 on Yosemite 10.10.1 (public release) on an original MacBook Pro 15" Retina, and Yosemite 10.10.2 (latest developer build) on a 2011 iMac, I get the following behaviour:
- 1Password mini tops the CPU table in Activity Monitor with values constantly ranging between 95% to 105%
- Accordingly, 1Password mini's energy impact also fluctuates around 100
- The absolute values are a little lower on the iMac, but still in the same overall ballpark of more than 90%. The iMac may be a little more powerful, or have a faster SSD; would need to check the details if that seems significant.
This behaviour starts immediately when unlocking 1Password mini, and also remains if I manually lock it. Only quitting the process (of course) will stop this from happening. On the other hand, a newly launched 1Password mini that hasn't been yet unlocked runs pretty much idle.
The effect in practice is that the battery of the MacBook Pro drains very fast if 1Password mini is running, unlocked even once. Recharging is also slowed down significantly, which of course is to be expected if a process maxes out a CPU core all the time.
The sync method I am using is a local folder that is synced by Synology Cloud Station among the two Macs and a Synology DiskStation. This behaviour, however, does occur even if nothing is being synced by that tool and when it is not even running.
Both Macs have SSDs as the main system drive.
Comments
-
Thinking it through, there is one false statement above, right at the top:
I only upgraded from Mavericks to Yosemite on the MacBook Pro with the release of Yosemite 10.10.0 in October, so I really have no idea about this behaviour under the Yosemite previews. I was only running them on the iMac, and never happened to check this stuff in Activity Monitor, as there is no battery drain to worry about. Apologies!
0 -
Hi @2pii,
I'm glad to hear that you've sorted it all out!
It is normal for 1Password mini to use more resources right after unlock, because it is responsible for syncing among other things. So as soon as you unlock your data, 1Password mini will start syncing it right away.
Hope that this helps :wink:
Cheers!
0 -
Hello,
Sorry if I wasn't entirely clear: the issue is not sorted out. I just tried to clarify, with the extra comment, that contrary to what I first wrote, I don't have any knowledge whether or not the problem occurred in the Yosemite developer previews with 1Password 4.
In any case, the problem certainly did not manifest itself with 1Password 4 on Mavericks. I would definitely have noticed because, to reiterate, the core issue is that 1Password mini's extreme CPU load will not stop, ever, after unlocking it.
Instead it will consume all MacBook Pro battery in less than two hours, in contrast to the 5 to 6 hours of work in Xcode I can normally get done.
Additionally I'll also note that I have been using the same Synology Cloud Station syncing solution from December 2013 without any problems until upgrading to 1Password 5.
Hopefully this clarifies the problem!
0 -
Hi @2pii
Sorry about that, sometimes it's easy to scan a message and pick up on the wrong parts, I hope you understand.
Now as for your CPU usage. Can you try something for me please, can you see if the issue persists if you disable Folder Sync. This is just for troubleshooting, if the problem is as extreme as you've suggested it is you should know fairly quickly and can then re-enable Folder Sync.
0 -
Sure, I'm happy to assist any way I can in resolving this!
After turning folder sync off on the MacBook Pro, an unlocked 1Password mini did indeed stop consuming so much CPU. This happened on the next launch of 1Password, though; an already running 1Password mini did keep going at it.
0 -
For comparison purposes, I checked my situation. I'm using a 13" MBP/Retina. I did this well after any sync had occurred.
0 -
Hi @2pii
We've seen something like this before but I don't think we've seen it with Folder Sync.
What worked in the past was disabling sync, removing the sync data and then restarting sync with a fresh sync repository either a new agilekeychain or opvault depending on the sync method used at the time (in your case it would be the agilekeychain format).
How would you feel about trying that out? If you're using Folder Sync and "Synology Cloud Station syncing solution" I'm figuring you're reasonably savvy with what you're doing. We can help you through the steps though if you wish. If that's the case can you describe in just a little detail how the Synology system works, if we're going to do this I want to make sure no version of the current keychain which seems to be associated with this issue is kept.
0 -
Ok, just tell me what to do. Savvy or not, I've implemented a syncing system (or three) myself, appropriately peppered with bugs, of course, so should be able to carry out some debugging instructions. :)
In my use case with 1Password, Synology Cloud Station works as follows:
- It has a server component running on a Synology DiskStation, which in my case is an Intel Atom-based headless Linux system (there are also ARM-based, less powerful models)
- Each Mac runs a client application that watches one or more local folders, and keeps them in sync with a server side folder
- Syncing mostly takes place via the local network at home. (The iMac is always connected via Ethernet, and the MacBook Pro either wirelessly or also using Ethernet whenever I remember to plug it in.)
- I do, however, also have a VPN connection set up, which allows the Macs to sync their 1Password keychain copies when I'm out of the house, working on the MacBook Pro.
- The file system on the DiskStation is ext4. I have no idea how well the whole Cloud Station client apps + server side chain syncs other details than actual file names and content, such as permissions or extended attributes. I'd venture to assume not that faithfully at all.
- I dropped Dropbox in favour of using Cloud Station with 1Password after a month-long test period late last year. Until October this year I never noticed any issues. (There is one more issue with 1Password 5 I should probably report, but I'll make a separate discussion about that later.)
Additionally, my iPhone's 1Password I have kept in sync with the Macs via WiFi sync, as there hasn't so far been a way for 1Password on iOS to sync the keychain via Cloud Station's iOS application.
0 -
Hi @2pii
The following instructions assume all of your vaults are currently in sync.
So what you will need to do is disable Folder Sync on each Mac. You can do that by going to the Backup tab in 1Password's preferences and clicking on the Change Syncing... button. You'll be asked to confirm and there is a checkbox for Delete data from the folder which you will want to tick.
Make sure the server side folder also has the 1Password.agilekeychain folder deleted. I'm figuring the deletion should get picked up by the client application on your Macs but better safe than sorry.
Once you're confident as you can be that there are no copies left of that version of 1Password.agilekeychain you're free to start re-enabling syncing again. From your setup I'm guessing you enable Folder Sync on one machine, let it propagate the agilekeychain and then point your other machines one by one to the sync location.
As your machines were in sync even if you get a warning and asked if you wish to merge you should be fine.
If everything has gone smoothly and there is no obvious signs of anything having gone wrong, try rebooting you MacBook Pro and see if the original issue reappears or if we've sorted it.
0 -
Good morning,
I did the above, and it did indeed resolve the issue: 1Password mini on both Macs now consumes significant energy only briefly when syncing, and then drops down to 0% CPU utilization. Excellent!
I have one further question, though, just to sanity-check the reliability of Cloud Station for this use:
When choosing Delete data from the folder, does 1Password literally only delete the data subdirectory under 1Password.keychain, and not the a/default hierarchy? That is what I observed happening here, and want to be sure Cloud Station synced every detail exactly as expected.
Finally, a clarification to my above assumption about what Cloud Station does sync: HFS+ extended attributes do get synced from Mac to Mac, as well as modification timestamps. It does not, however, sync file permissions or group & ownership attributes, which is only prudent, with easily imaginable issues when different Macs can have different users and groups set up.
In any case, thanks for the help!
0 -
Hi @2pii,
I'm happy to hear the steps from @littlebobbytables solved the problem, thanks for letting us know! :smiley:
To answer your question, when you disable sync and choose Delete data from the folder, 1Password will delete the entire 1Password.agilekeychain bundle, not just the subdirectories it contains. Where did you see that only the data subdirectory was deleted? The .agilekeychain directory should have been immediately moved to the Trash from its prior location on your Mac.
It sounds like it worked out ok, so it's nothing to worry about. But if you have more questions about that, please let us know.
0 -
Hello,
Looking at the contents of the trash folder on the iMac, the full 1Password.agilekeychain bundle is indeed there, with the correct Date Added timestamp, so clearly 1Password did the right thing.
At the same time, what I saw happening yesterday was that 1Password.html and the a/default/files subdirectory hierarchy still did exist on both Macs and on the DiskStation after Cloud Station said "Up to date" on all machines. Hence, before restarting folder sync on the iMac, I manually deleted these remnants of 1Password.agilekeychain on the DiskStation, and that deletion then did get synced to the Macs.
This is slightly worrisome in that I've witnessed this kind of inexplicable failures to propagate file system changes when developing various applications' syncing functionality on some public cloud services, and in most cases such failures have then turned out to be showstoppers. (Dropbox in my experience has been clearly the most reliable, although not absolutely perfect, either.)
Then again, things still seem to work just fine, so there's no immediate need to abandon Cloud Station yet. Just annoying to not be 100% certain it works... Ignorance would be bliss. :)
0 -
Hi @2pii,
What was likely happening is that something was causing sync to be stuck in a loop. We've found a few scenarios where this could happen in all of our sync implementations. The sync process is expensive from a power consumption point of view... it needs to look at all of your data to determine what has changed, it needs to read the data in the agilekeychain to determine what has changed there, perform all of the merges then write that back to our database (and possibly the agilekeychain itself). By resetting sync you're starting things back from a clean slate and things tend to work well there. If you find yourself in a similar situation in the future, getting us a Diagnostics Report would give us some idea of where to start looking to find the loop.
We've fixed a all of the "stuck in a loop" sync bugs that we've been able to find, and they'll be released as part of 1Password for Mac 5.1.
Cheers.
Rick
0
