Backing up Vaults slow

IS there a time difference between backing up to the internal as opposed to the Drobo?

Is your Drobo a NAS?

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.

good luck

Perhaps change tack slightly. Update the internal vault, then copy it to the Drobo.

Andy

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..

regards