Wehikuł czasu śmiesznie zwalnia po aktualizacji El Capitan

55

Niedawno zaktualizowałem do El Capitan i powiedziałem Time Machine, aby wykonał kopię zapasową. Utknął podczas przygotowywania kopii zapasowej przez kilka godzin, więc zatrzymałem go, usunąłem plik InProgress, uruchomiłem ponownie i spróbowałem ponownie. Po około 30 minutach wehikuł czasu wciąż się przygotowywał. Spojrzałem na monitor aktywności i kopia zapasowa odczytała tylko ~ 140 Mb, w 30 minut ... Patrząc na iStatMenus, stwierdzam, że kopia zapasowa ma prędkość odczytu od zera do 120 Kb / s (jeśli mam szczęście. Czasami wzrasta) do 500 kb / s, a bardzo rzadko 1 Mb / s). Spotlight nie indeksuje (jak czasem słyszę, że Spotlight przeszkadza w tworzeniu kopii zapasowych), a dysk twardy poszedł spać w czasie, gdy to pisałem, rzadko budząc się, aby mój Mac krótko przeczytał coś z niego.

Oto, co pojawia się w konsoli podczas wyszukiwania kopii zapasowej: Dziennik konsoli

Raczej nie będę musiał ponownie formatować dysku twardego, na wypadek, gdyby kiedykolwiek chciałem przywrócić Yosemite do poprzedniej wersji, ale chętnie, jeśli to rozwiąże problem.

Wydaje się również, że za każdym razem, gdy uruchamiam ponownie komputer Mac, dysk twardy traci ikonę Wehikułu Czasu i powraca do pomarańczowego dysku.

Zrzut ekranu Monitora aktywności, tryb dysku przy znaku ~ 50 min: Monitor aktywności

EDYCJA: Próbowałem wyłączyć i ponownie włączyć Spotlight dla dysku, a także wyczyściłem folder .Spotlight-V100 i uruchomiłem ponownie. Brak zmiany.

EDYCJA 2: W konsoli pojawiły się jakieś błędy Błądzić

EDYCJA 3: Po wielu, wielu godzinach Time Machine zakończyło skanowanie i teraz wykonuje kopię zapasową! Wciąż chciałbym wiedzieć, dlaczego to trwało tak długo (nie spodziewałem się, że aktualizacja do El Capitan zajmie tak dużo czasu. Wykluczyłem również pliki systemowe, chociaż myślę, że czeka mnie kolejne długie oczekiwanie, odkąd je usunąłem z listy wyjątków)

CraftedCart
źródło
2
Walczę z tym samym problemem, od kiedy uaktualniłem do El Capitan. Zaszyfrowane kopie zapasowe stały się absurdalnie wolne, szczególnie w sieci. Pytanie na forach nie pomogło. Dla niektórych osób wydaje się, że wystarczy poczekać na pierwszą kopię zapasową. Kolejne kopie zapasowe powinny być szybsze. Nie działało dla mnie, a mój komputer rzadko jest podłączony do tego samego magazynu kopii zapasowych przez ponad 12 godzin. Porzucę wehikuł czasu dla rozwiązania do tworzenia kopii zapasowych innych firm. Porażka.
Huitzilo,
@Huitzilo Rozpoczęcie tworzenia kopii zapasowej przez TM zajęło mi około 12 godzin. Wydaje się, że byłoby to dla ciebie wolniejsze, ponieważ szyfrujesz je i robisz to przez sieć (ja nie byłem). : / Oczekiwanie na to zadziałało, a przyszłe kopie zapasowe były szybsze ...
CraftedCart

Odpowiedzi:

77

Częścią problemu jest to, że operacje wejścia / wyjścia (I / O) o niskim priorytecie wydają się teraz mocno ograniczone. Możesz to sprawdzić przez Terminal (można go znaleźć przez Spotlight (zwykle związany Space) i wchodząc terminal), a następnie wchodząc po znaku zachęty:

fs_usage backupd

i poszukaj THROTTLEDwpisów. Jeśli je zobaczysz, kopia zapasowa jest ograniczona.

Więc jeśli masz mnóstwo plików, czas potrzebny na wykonanie operacji we / wy trwa wiecznie, nawet jeśli pliki są małe (ponieważ wykonuje o wiele więcej operacji we / wy xattrsitp. Niż wcześniej).

Idź do terminalu i wpisz:

sudo sysctl debug.lowpri_throttle_enabled=0

Dla mnie przyspiesza to od 72 godzin do ~ 4 godzin w systemie plików z 2,5 milionami plików.

Dobrym pomysłem jest również ponowne włączenie ograniczania przepustowości po pomyślnym zakończeniu tworzenia kopii zapasowej za pomocą następującego polecenia

sudo sysctl debug.lowpri_throttle_enabled=1
Daniel Berlin
źródło
Miałem kopię zapasową, która trwała wiele godzin, aby odczytać dysk, i nie udało mi się wykonać z dnia na dzień serwera. Działał, powoli przenosząc bajty po bajtach. Uruchomiłem to polecenie w terminalu i nagle zaczęło płonąć szybko z kilku bajtów / s do megabajtów / s. Dziękuję bardzo !!
Jean
Wydanie a man sysctlpokazuje następujący komunikat: „Opcja -w została uznana za przestarzałą i jest dyskretnie ignorowana” . Zakładam więc, że nie jest konieczne zapisywanie wartości. Czy to jest poprawne?
yan
@yan To prawda, możesz po prostu pominąć -wi będzie działać.
DASKAjA
1
Za pomocą sudo fs_usage backupdwidziałem wiele wpisów, ale nie mogłem znaleźć słowa kluczowego THROTTLEDani throttled(za pomocą grep). Mimo tego po ustawieniu debug.lowpri_throttle_enabledna 0Time Machine wykonanie kopii zapasowej moich 155 GB danych zajęłoby 3 godziny, zamiast nigdy nie kończyć oszacowania. Cieszę się, że znalazłem ten wątek.
Steven C. Howell,
9
Dlaczego powinniśmy to włączyć ponownie? Jakie są zalety / wady profesjonalistów, jeśli zostały na stałe wyłączone
Tom
11

Potwierdzam, że polecenie:

sudo sysctl debug.lowpri_throttle_enabled=0 

działa świetnie.

Jeśli chcesz, aby była stała podczas ponownego uruchamiania, możesz wykonać następujące czynności.

  • utwórz plik pod /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
      <dict>
        <key>Label</key>
        <string>fix-el-capitan-slow-time-machine-speed</string>
        <key>ProgramArguments</key>
        <array>
          <string>/usr/sbin/sysctl</string>
          <string>debug.lowpri_throttle_enabled=0</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
      </dict>
    </plist>
    
  • upewnij się, że plik należy do katalogu głównego

    sudo chown root /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
    
  • wydać polecenie

    sudo launchctl load /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist
    

Można znaleźć zawartość pliku w tym GIST

yan
źródło
Lub możesz dodać linię do /etc/sysctl.conf; tam przechowuję wszystkie moje dostosowania sieciowe i zawsze dla mnie działał.
Jamie Iwanow
3

Znalazłem ten artykuł na forach dyskusyjnych firmy Apple na temat komunikatu wyświetlanego w konsoli (gdy nic nie robi lub nie wykonuje kopii zapasowej z prędkością 10 bajtów / sekundę):

com.apple.backupd: Waiting for index to be ready (100)

W moim przypadku udało mi się odrzucić wszystkie stare kopie zapasowe, więc zdemontowałem wolumin z kłopotliwego komputera Mac, zamontowałem napęd / udział sieciowy na innym komputerze (nie Mac), usunąłem cały .sparsebundlekatalog (co zaskakująco długo trwało) i następnie ponownie uruchom kopię zapasową. Stworzył nowy .sparsebundlei teraz tworzy kopię zapasową z prędkością około 10 MB / s.

Jeśli nie chcesz usuwać istniejących kopii zapasowych, możesz wypróbować jedną z innych sugestii na tej stronie:

  • ponowne uruchomienie w trybie awaryjnym, a następnie powrót do normalnego trybu;
  • powiedz Spotlight, aby nie indeksował woluminu / dysku Time Machine;
  • usuwanie indeksu Spotlight .Spotlight-V100(którego nie miałem);
  • Używanie mdutildo wyłączania i ponownego włączania indeksowania Spotlight w woluminie:
    • sudo mdutil -i off /Volumes/Time\ Machine\ Backups
    • sudo mdutil -i on /Volumes/Time\ Machine\ Backups

(więcej szczegółów i pomysłów znajdziesz w tej dyskusji).

qris
źródło
2

Miałem podobne problemy po przeprowadzce do El Capitan - kopie zapasowe (nawet małe przyrostowe) zwolniły do ​​prawdziwego pełzania. Zrobiłem więc wireshark zrzut rozmowy między komputerem Mac a serwerem NAS i zobaczyłem liczne nieudane żądania FPGetFileDirParms. AFP jest (był?) Protokołem czasu używanym przez maszynę czasu do komunikowania się z dyskami NAS, ale przeczytałem, że przechodzą na SMB.

174 0.390744    192.168.0.9 192.168.0.10    AFP 107 FPGetFileDirParms request: Vol=3 Did=62779 Name=._1b6c
176 0.391729    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object not found (-5018)[Malformed Packet]
178 0.392002    192.168.0.9 192.168.0.10    AFP 101 FPGetFileDirParms request: Vol=3 Did=93632
179 0.392909    192.168.0.10    192.168.0.9 AFP 82  FPGetFileDirParms reply: object is the wrong type (-5025)[Malformed Packet]

Nie mam pojęcia, dlaczego te żądania nie powiodły się, ale liczba tych nieudanych prób jest OGROMNA - rzeczywiste przesłane dane są minimalne w porównaniu do liczby tych nieudanych próśb - a zatem powolna, pełzająca szybkość.

Dla mnie zadziałało:

  1. Poszedłem do Time Machine Preferences-> Select Disk i usunąłem aktualnie skojarzony dysk (który był podłączony do afp: //MyBookLive.local/TimeMachine)
  2. Poszedł do Findera-> Idź-> Połącz z serwerem. Wpisano adres IP dysku NAS w przestrzeni „Adres serwera” (smb: //192.168.0.10 dla mnie)
  3. Połączyć. Wyrzucił listę woluminów do zamontowania - wybrał wolumin używany w maszynie czasu (dla mnie TimeMachine). TimeMachine został zamontowany w / Volumes.
  4. Z terminala uruchomiono:

    sudo tmutil setdestination /Volumes/TimeMachine
    

Otóż ​​to. Wehikuł czasu jest teraz powiązany z / Volumes / TimeMachine zamiast afp: //MyBookLive.local/TimeMachine. Poprzednie kopie zapasowe były dobre, a przyrostowe kopie zapasowe, które miały miejsce po tym, były SZYBKIE. Zrzut Wireshark, który zrobiłem po tym, nie wykazał nieudanych żądań AFP (chociaż AFP wciąż był w użyciu protokołu).

msravi
źródło
2
Uruchomienie tmutil kończy się niepowodzeniem z „/ Volumes / TimeMachineBackup: Niezgodny typ systemu plików: smbfs (błąd 45)” dla mnie.
Nate
Czy wolumin TimeMachine na dysku sieciowym ma format sparsebundle? Kiedy używasz Findera do zamontowania woluminu kopii zapasowej, czy widzisz obraz sparsebundle?
msravi
Występuje ten sam błąd „Niezgodny typ systemu plików: smbfs” jak @Nate. Usunięto sparseimage, ale nie pomaga. Dotyczy to OS X 10.11.3, w kierunku nowoczesnej kapsuły czasu 3 GB.
akauppi,
0

Nie byłem w stanie naprawić problemu, jednak odkryłem, że mój wehikuł czasu zwalnia, gdy tworzy kopie zapasowe danych innych użytkowników (niezalogowanych). Być może istnieje problem z uprawnieniami w plikach folderów innych użytkowników. Kiedy dodałem tego użytkownika do listy wyjątków, TM się kołysze.

Viet Le
źródło
0

W związku z odpowiedzią Daniela Berlina powyżej (ale jestem tu nowy, więc nie mam wystarczającej wiarygodności, aby po prostu tam skomentować), znalazłem jego terminalową komendę, by działała WIELKO dla mnie w OSX 10.11.3. Przekształcono 30-godzinną kopię zapasową w 4-godzinną! Nie pozostaje jednak po ponownym uruchomieniu.

Nie chciałem wpisywać w terminalu przy każdym ponownym uruchomieniu, więc ...

Ponieważ nie jestem zbyt dobrze zaznajomiony ze skryptami powłoki, przeszukałem wystarczająco dużo, aby utworzyć przepływ pracy Automatora, który monituje użytkownika o podanie hasła roota, a następnie wykonuje polecenie terminalu. Zdecydowałem się potwierdzić sukces powiadomieniem centrum powiadomień.

Zapisałem przepływ pracy jako aplikację i dodałem go do moich elementów logowania. Więc teraz przy każdym logowaniu jestem proszony o ponowne wpisanie hasła do „odblokowania” Wehikułu Czasu.

Istnieją sposoby, aby uczynić ten proces niewidocznym za pomocą skryptów powłoki, ale jest to trochę skomplikowane wymaganie dostępu do konta root uzyskanego przez polecenie sudo. Można również ustalić hasło w aplikacji Automator, jeśli nie martwisz się o bezpieczeństwo. (Nie polecam.)

Zamieszczę tutaj aplikację przepływu pracy, ale najwyraźniej nie mogę przesłać pliku do tej odpowiedzi. Załączę plik jpg, aby każdy mógł go odtworzyć, jeśli chce. PS Zwróć uwagę na „Pass argument” jako argument dla skryptu powłoki

Skrypt Automatora

BenW
źródło
0

Mój problem został rozwiązany w artykule DWHoard : uruchom ponownie w trybie awaryjnym, a następnie z powrotem (dla mnie komputer wydawał się wyłączać podczas bezpiecznego rozruchu).

Macbook Air z połowy 2011 r., OS X 10.11.3, kopia zapasowa do Time Capsule.


Edycja: Właściwie wydaje się, że po bezpiecznym rozruchu i normalnym rozruchu Time Machine osiągnął tylko około 41/55 GB (w ciągu godziny) i ponownie zaczął się czołgać (od tego czasu zwiększył się tylko o 2,75 GB w ciągu 12 godzin). kupiłem Time Capsule tylko po to, aby uniknąć tego rodzaju niezgodności i oto jestem - wszystkie urządzenia Apple i kiepskie doświadczenie, strata czasu. Mam nadzieję, że inni znajdziecie trwałe rozwiązanie.

Konsola otrzymuje nowy wpis na mdworkermniej więcej każdą sekundę - czy to normalne, gdy trwa tworzenie kopii zapasowej?

zrzut ekranu


Edycja 2: Udane! Laptop ma dwa konta użytkowników i może się zdarzyć, że zalogowanie się do drugiego spowoduje kontynuację reszty kopii zapasowych. Warto przetestować, jeśli jesteś w podobnej sytuacji.

akauppi
źródło
-1

Mam ten sam problem i znalazłem to, co wygląda na rozwiązanie (nie wspaniałe, ale działa)

sformatuj zewnętrzny dysk twardy i sprawdź, czy masz naprawdę dobre pasmo (przetestuj USB3), zwróć uwagę na ustawienia TM, tutaj zapomniałem tylu innych partycji i obrazów dysków, że nie chcę tworzyć kopii zapasowej, zwiększyłoby to czas bck . uruchom pierwszą kopię zapasową. KAŻDY 2-3 godziny, uruchom ponownie komputer. (Tak, nie jest fajnie, ale zauważyłem, że pierwsza godzina jest zwykle szybka, a po tym czasie staje się wolniejsza) to wszystko, mogłem wykonać kopię zapasową 1,5To rano. .

raoulito
źródło
3
Czy możesz dodać źródło wyceny w celach informacyjnych?
nohillside
-2

Zobacz tę notatkę od Apple :

OS X El Capitan: Jeśli wehikuł czasu jest wolny

Wypróbuj te sugestie, jeśli Time Machine działa wolno.

  • Przy pierwszym użyciu Time Machine skonfiguruj go wieczorem, aby początkowa kopia zapasowa mogła zostać wykonana przez noc.

  • Jeśli dyskiem kopii zapasowej jest Time Capsule, zostaw komputer Mac w tym samym pomieszczeniu, co Time Capsule, aby wykonać początkową kopię zapasową lub użyj kabla Ethernet, aby podłączyć komputer Mac do jednego z portów Ethernet na Time Capsule.

  • Oprogramowanie do skanowania w poszukiwaniu wirusów może bardzo powolnie tworzyć kopie zapasowe Time Machine. Jeśli korzystasz z programu Norton AntiVirus lub podobnego produktu, spróbuj wykluczyć dysk kopii zapasowej z automatycznego skanowania. Upewnij się również, że korzystasz z najnowszej wersji oprogramowania antywirusowego.

użytkownik155661
źródło