Czasami widzę, że distnoted
proces nagle się rozkręca i żuje 100% procesora (na jednym rdzeniu) i tonę pamięci, często w okolicach 1,5G. Zdarza się to kilka razy dziennie, zaczynając mniej więcej miesiąc temu.
Wiersz poleceń jest /usr/sbin/distnoted agent
i jest uruchamiany przez launchd
, z których żadne z nich nie pomaga. Zwykle działa od około 4 godzin do 24 godzin, zanim się włączy i ustali procesor.
Wyszukiwania internetowe mówią, że distnoted
zarządza dostarczaniem powiadomień, a wiele innych osób zgłasza ten sam problem, ale nie znalazłem jeszcze rozwiązania. Niektórzy uważają, że zamknięcie aplikacji sprawcy (np. Skype) ją zatrzymuje, ale nie znalazłem jeszcze winowajcy na moim komputerze. Zwykle korzystam tylko z kilku aplikacji: Emacs (24.2 z Homebrew), Firefox, Adium i Dash.
Korzystam z Mavericks pod koniec 2012 13 "Retina MBP. Z góry dziękuję!
Aktualizacja:
Włączyłem distnoted
logowanie do dziennika systemowego, dotykając /var/log/do_dnserver_log
, ale to niewiele pomaga. Widzę takie linie (uid 501 to ja, 89 jeszcze nie znalazłem):
distnoted[80011]: # distnote server agent absolute time: 48754.144787848 civil time: Wed Nov 20 10:52:03 2013 pid: 80011 uid: 501 root: no
distnoted[20]: # distnote server daemon absolute time: 2.808112262 civil time: Tue Nov 19 09:52:24 2013 pid: 20 uid: 0 root: yes
distnoted[444]: # distnote server agent absolute time: 16.656997509 civil time: Tue Nov 19 09:52:38 2013 pid: 444 uid: 501 root: no
distnoted[1271]: # distnote server agent absolute time: 52.518265717 civil time: Tue Nov 19 09:53:14 2013 pid: 1271 uid: 89 root: no
distnoted[689]: Interruption - exiting now.
Uruchomiłem również proces sudo dtruss -p PID
rozpędzania distnoted
, który wyrzuca linie takie jak to:
kevent64(0x3, 0x7FFF7C3FD130, 0x1) = 1 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1) = 1 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1) = 1 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
__disable_threadsignal(0x1, 0x0, 0x0) = 0 0
__disable_threadsignal(0x1, 0x0, 0x0) = 0 0
__disable_threadsignal(0x1, 0x0, 0x0) = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1) = 1 0
workq_kernreturn(0x20, 0x0, 0x1) = 0 0
...
Odpowiedzi:
Podsumowanie z PO : To było świetne narzędzie do debugowania. Początkowo wskazywało to na ponowne indeksowanie systemu plików przez Spotlight, ale zawęziłem listę elementów, które wolno indeksować, i nadal widziałem problem. Skończyło się na ustawianiu pracy crona, by zabijać regularnie. Zobacz odpowiedź dalej.
Można debugować z rozproszeniem, tworząc plik.
/var/log/do_dnserver_log
Powoduje to, żeCFNotificationCenter
serwer (distnoted
) zapisuje informacje o wszystkich powiadomieniach w dzienniku systemowym.Zacznę od tego, uruchomię ponownie i spojrzę na dziennik systemu, kiedy procesor przyspieszy. To powinno łatwo wyjawić winowajcę.
Więcej informacji na temat
CFNotificationCenter
debugowania można znaleźć w oficjalnych dokumentach programistów tutaj: Nota techniczna TN2124> CFNotificationCenterźródło
/var/log/system.log
, ale również nie wyskoczył od czasu rozpoczęcia logowania. skrzyżowane palce.Nov 23 07:56:15 hell.local distnoted[2644]: # distnote server agent absolute time: 77.445654904 civil time: Sat Nov 23 07:56:15 2013 pid: 2644 uid: 89 root: no
sudo dtruss -p PID
i zobacz, jakie syscalls robi ten proces, a jeśli są jakieś nieudane (status nie jest równy 0).strace
, ale nie wiedziałem o tymdtruss
. na pewno spróbuję to następnym razem. pids są po prostu odpowiadającym rozproszonym procesem, a jedyne uids to ja i_appserveradm
wbudowany użytkownik systemu, o którym niewiele wiem.Też to widziałem. Emacs 24.3.1, Mavericks 10.9.
Przekonałem się, że rozproszony proces uspokaja się w ciągu kilku sekund po wyjściu z Emacsa.
Złożyłem tutaj błąd Emacsa: http://permalink.gmane.org/gmane.emacs.bugs/80836
źródło
Wiem, że jestem spóźniony na imprezę, ale jest to wyciek pamięci związany z emacami kakao na Mavericks, który jest naprawiony w bagażniku. Na razie jest łatka, której możesz użyć do zbudowania emacsa 24.3 za pomocą samej poprawki.
https://gist.github.com/anonymous/8553178
źródło
brew reinstall emacs --cocoa --with-gnutls
może rozwiązać problem. Ma to również zostać naprawione w wersji 24.4, ale nie osiągnęło to jeszcze stabilności.top
) i zabicie -9 emacsa nie działało, ale po zabiciu -HUP disnoted emacs odpowiedział na zabójstwo.Od
distnoted
pewnego czasu mam te same problemy z El Capitan. Moje rozwiązanie nie jest tak surowe jak regularne zabijanie, raczej sprawdzam, czy wymyka się spod kontroli (wysokie użycie procesora), a następnie zabijam. Używam tego skryptu:Skrypt jest uruchamiany z crona co minutę z następującą linią w crontab:
W praktyce skrypt zabija
distnoted
raz lub dwa razy dziennie i zwykle dzieje się to po uruchomieniubackupd
.Dla tych, którzy nie są zadowoleni z używania powłoki OS X (wiersz poleceń), następujący skrypt zainstaluje zarówno
checkdistnoted
skrypt, jak i pozycję crontab:Musisz zapisać powyższe
install_checkdistnoted.sh
na pulpicie, a następnie uruchomićApplications/Utilities/Terminal
i wpisać:Jeśli działa w pełni, wydrukuje potwierdzenie każdego z kroków. Skrypt nie nadpisze istniejącego
checkdistnoted
wpisu skryptu lub pliku crontab.źródło
poddałem się i przyjąłem młot kowalski: zabijaj go automatycznie, co minutę. westchnienie.
umieszczam to w
~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist
:a następnie zainstalowałem za pomocą
launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist
.źródło
disnoted
jedzenia RAM.disnoted
wczoraj 63 GB pamięci RAM na mojej High Sierra. Nawet Ryan, w swoim pytaniu, stwierdza, że proces żucia się mnóstwo pamięci .Robiłem różne kombinacje dostosowywania stripingu, aby zawęzić to zachowanie; Myślę, że to tryb komend. W wersji 10.9 z emacs 24.3.1 z homebrew (lub z emacsforosx) rozproszony + wyciek emacsa (oba powoli zwiększają zużycie pamięci) nastąpi przy otwartym buforze w trybie powłoki. Nie zrobi tego, jeśli tylko przejdziesz do plików.
Chciałem tylko to tutaj zauważyć, gmane wydaje się być wyłączony i wciąż znajduję tę dyskusję podczas moich dwa razy w tygodniu poszukiwań kontynuacji tego problemu.
źródło
Wydaje mi się, że pamiętam tylko dwa przypadki, w których rozproszony szaleje. Przy tej okazji 2 z nich siedziały na szczycie listy procesorów, a jeden miał ponad 400%. Stało się to krótko po powrocie do biura i podłączeniu kilku zewnętrznych wyświetlaczy - z których jeden jest zasilany z portu USB - domyśliłem się, że może to być związane. Nie zrobiłem nic innego, aby spróbować rozwiązać problem, zanim wyciągnąłem wyświetlacz USB, co natychmiast przywróciło zdrowie psychiczne. A następnie podłączenie go ponownie nie spowodowało powtórzenia problemu.
Co udowadnia co? Brak pomysłu!
Podłączam je setki razy i po raz pierwszy przyszło mi do głowy, że może to być związane. A ponieważ nie zdarza się to za każdym razem, gdy je podłączam, może to mieć coś wspólnego ze zbyt szybkim podłączaniem ich obu do siebie, lub czymś losowym. W każdym razie pomyślałem, że podzielę się, na wypadek gdyby inni zauważyli, że ma to coś wspólnego z podłączaniem urządzeń peryferyjnych (jeśli taki jest ekran zewnętrzny)
źródło
Wydaje się, że dzieje się tak, gdy aplikacja w niewłaściwy sposób korzysta z interfejsu API powiadomień udostępnianego przez system macOS. W moim przypadku winowajcą był iTerm2. Po wyjściu z
distnoted
procesu procesy zakończyły się. Inni zidentyfikowani sprawcy to Emacs i iTunes.źródło
Warto było rozwiązać ten problem, wyłączając oprogramowanie antywirusowe.
źródło
To samo mi się przydarzyło, rozpaczało szaleć. Po zamknięciu wielu aplikacji nic nie pomogło.
Potem zauważyłem, że jedno z okien dialogowych „Zgłoś się do Apple'a” z powodu zawieszonego procesu Pythona pozostało otwarte przez całą noc.
Choć może to być po prostu zbieg okoliczności, po zamknięciu okna dialogowego rozproszony proces uspokoił się.
źródło
Kilka miesięcy temu natknąłem się na podobny problem z rozproszeniem i nie mogłem wyśledzić, dlaczego użycie procesora wzrosło powyżej 100%. W końcu dodawałem wpis do mojego crontab
killall distnoted
co 2 minuty, co rozwiązało mój problem.Ostatnio miałem problem z Sublime Text, w którym pisanie
subl path/to/file
nie otwierało się poprawnie w Sublime Editor. Ponowne uruchomienie aplikacji rozwiązało problem, ale szybko zaczęło się to powtarzać.Po tym, jak bez końca dokuczałem mózgowi, stwierdziłem, że zabijam rozproszony proces co 2 minuty, dlaczego polecenie subl w tajemniczy sposób przestało działać.
Wniosek: bardzo wysokie użycie procesora mogło być związane z wysublimowaniem. Teraz, gdy sublime zostało zaktualizowane, mam nadzieję, że mój wniosek jest poprawny, użycie procesora pozostaje niskie, a moje polecenie subl powraca do pracy zgodnie z oczekiwaniami, teraz, gdy distnoted działa ponownie bez mojej crontab zabijającej proces co 2 minuty.
źródło
Ja też miałem ten problem od dłuższego czasu, ale sporadycznie. Najwyraźniej jest to część iTunes i spowodowało problemy również w systemie Windows . Kiedy zabiłem iTunes (który odtwarzał utwór),
distonted
proces, który zużywał 400% mojego procesora (mam 4 rdzenie) przestał być problemem.Tak więc moją odpowiedzią, dopóki nie będę wiedział lepiej, jest zalecenie zabicia iTunes, a nie
distnoted
poinformowanie nas, co się stanie.źródło
Widzę też rozróżnione szaleństwo, w moim przypadku wydaje się, że jest związane z fontd. Mam trzy uruchomione, jeden dla _spotlight, jeden dla _distnote i jeden dla mojego użytkownika.
Kiedykolwiek rozproszony zjada procesor (30-90%), fontworker i fontd zjadają około 30-60% procesora każdy. Jak tylko zabiję fontd, distnoted i fontworker dla mojego użytkownika uspokaja się. Zabijanie fontworkera nic nie robi. Po kilku minutach, gdy fontd zrestartował się i zaczął działać przez chwilę, wszystko zaczyna się od nowa.
Nie mam pojęcia, dlaczego tak się dzieje…
źródło
Peter Buckley ma rację, mylę się. Nienawidzę tego, kiedy to się dzieje.
Nie usuwaj rozproszonego, następny rozruch nie będzie wcale zabawny.
źródło
distnoted
jak wspomniał ConorR (a później poprawiony, dzięki!), Wymagane jest uruchomienie OSX (10.9.5 w moim przypadku).