11 Replies Latest reply: Dec 17, 2013 8:29 AM by woowooz
woowooz Level 1 Level 1 (0 points)

Using Aperture 3.4.5 on a Mac Pro with 10GB Ram, updating a vault takes hours.  Activity Monitor indicates "Not Responding" in red.  When it is not marked "Not Responding", Aperture is using 0nly 1.2% of CPU, even with no other application running.  Eventually it completes the update.  Is there a way to force Aperture to use more of the CPU capacity so that this process would go faster?  I have two libraries, one 301 GB and the other 1.67 GB, and this problem occurs with both libraries.  Each library has two vaults, one on a Drobo and one on an internal drive in the Mac Pro.

  • 1. Re: Backing up Vaults slow
    Frank Caggiano Level 7 Level 7 (23,820 points)

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

  • 2. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    Have not kept track.  Both take many hours (4+)

  • 3. Re: Backing up Vaults slow
    léonie Level 9 Level 9 (51,665 points)

    Is your Drobo a NAS?

  • 4. Re: Backing up Vaults slow
    Frank Caggiano Level 7 Level 7 (23,820 points)

    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

  • 5. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    Firewire 800.

  • 6. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    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:

    https://discussions.apple.com/message/23930697#23930697

     

    Since the update of the internal vault went so quickly, I did not notice whether this occurred during that update.

  • 7. Re: Backing up Vaults slow
    Najinsky Level 3 Level 3 (670 points)

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

     

    Andy

  • 8. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    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 Screen Shot 2013-11-26 at 7.48.26 PM.png

    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!

  • 9. Re: Backing up Vaults slow
    Frank Caggiano Level 7 Level 7 (23,820 points)

    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

  • 10. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    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 warningsScreen Shot 2013-12-13 at 2.04.34 PM.png

    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.

  • 11. Re: Backing up Vaults slow
    woowooz Level 1 Level 1 (0 points)

    Followup:  Updating to OS 10.9.1 today has solved Aperture vault update problems AND I no longer get QTKitServer hangs, either using Aperture or in Safari.  Good for Apple!