I do know that Drobo's can be slow when doing these types of operations. It would be interesting to do each one in turn and see what the difference is.
In the meantime I have found that doing a repair to the library just before doing a vault update helps move things along.
A few other things that might help isolate the problem, If you do a vault update and let it run to conclusion and then make one change to the library, import an image say, and then do another vault update how long does it take?
You could also create a new vault and update that and see if it here is a difference in the time it takes to do the update. Remember in this case it will be doing a complete copy of the library rather then just doing the changes.
Currently Being ModeratedNov 26, 2013 8:27 PM (in response to Frank Caggiano)
I'm working on your suggestions, Frank. I did a library repair, then updated to the internal drive and it took only a few minutes. Then updated the second vault, on the Drobo, now 2 1/2 hours running. It may be that a "QTKitServer-(9798) Aperture (Not Responding)" problem may be related. See my post on another forum here:
Since the update of the internal vault went so quickly, I did not notice whether this occurred during that update.
Currently Being ModeratedNov 27, 2013 5:28 AM (in response to Frank Caggiano)
Frank, I did a Photo Library Repair Permissions, then Repair Database. Now the Vault updates take only minutes! Even though much improved, I am still puzzled by the Activity Monitor showing the red " Aperture not responding" message, sometimes but not always accompanied by
Further, I don't understand why Aperture is using only 2% of CPU during these vault updates. Why not use more CPU and speed things up? There are other threads discussing this QTKitServer issue--see my last post.
Thanks for your help!
Frank, I did a Photo Library Repair Permissions, then Repair Database. Now the Vault updates take only minutes!
Ok that's good. As I wrote I found that doing a repair before vaulting seems to help especially if the library has had a lot of changes to it or its been a while since a repair or a vault operation.
Even though much improved, I am still puzzled by the Activity Monitor showing the red " Aperture not responding" message, sometimes but not always
That is deceiving and not always helpful. An application can be non-responsive to the outside world but it doesn't necessarily mean the app is hung. It just means it is doing some intensive task at that moment. This cause a lot of problems as user see this and think the app is hung and then force quit it.
Especially in this case where it is going in and out of the not responding state everything is OK.
Further, I don't understand why Aperture is using only 2% of CPU during these vault updates. Why not use more CPU and speed things up?
Updating a vault is just not very CPU intensive, not a lot of computation going on. The bottleneck is really the I/O, reading the library and writing to the vault. More CPU really wouldn't help in this case.
There are other threads discussing this QTKitServer issue--see my last post.
Yeah I've seen those too, not sure what is going on with that. Seems to be a fairly recent thing, I'll have a look at the other thread..
Currently Being ModeratedDec 13, 2013 2:16 PM (in response to Frank Caggiano)
Further followup. Today I successfully backed up an Aperture library to its Vault 1 (to a Drobo), but in attempting to back up the same library to its vault 2 (on an internal HDD), Aperture has been hung now for 4 hours with one or more QTKit server warnings
I do not know why QTKitServer would be involved in updating an Aperture library, but it is. Anyone have a solution.\? Hate to Force Quit Aperture.