Coreduetd загружает процессор Mac

Обновлено: 05.07.2024

В последние несколько дней я заметил высокую загрузку ЦП на моем iMac из-за процесса videosubscriptionsd. Я не знаю, откуда это взялось. В моей пользовательской папке есть база данных, в /Application Support/videosubscriptionsd/.

Кто-нибудь еще видит загрузку ЦП этим процессом? На форумах поддержки Apple есть несколько тем, но я не могу найти больше информации об этом демоне.

40 мыслей на тему “Высокая загрузка ЦП в macOS из процесса videosubscriptionsd”

У меня высокая загрузка ЦП из-за процесса Assistanced. Если я зайду в Activity Monitor и форсирую процесс, загрузка ЦП вернется к норме, а температура ЦП вернется к разумному уровню. Если я погуглю процесс с помощником, то обнаружу, что он связан с SIRI. Я не использую SIRI и никогда не хочу его использовать. Ни на моем iMac, ни на моем iPhone. К сожалению, через пару часов процесс перезапускается, и мне приходится следить за уровнем загрузки процессора и снова принудительно завершать его. Так разочаровывает. Так было с тех пор, как Sierra была выпущена. Если у кого-то есть идеи по этому поводу, буду рад их услышать. Спасибо.

Системные настройки > Клавиатура > Диктовка. Диктовка включена?

Я никогда не использовал диктовку, но все равно проверил. Это набор «выкл.». Спасибо за идею.

Системные настройки > Клавиатура > Диктовка. Диктовка включена?

Я никогда не использовал диктовку, но все равно проверил. Это набор «выкл.». Спасибо за идею.

/usr/libexec/videosubscriptionsd (более правильно обозначаемый как com.apple.VideoSubscriberAccount.videosubscriptionsd) является частью службы подписки на видео с единым входом, которую Apple представила в OSX/tvOS/iOS. Это часть структуры учетной записи подписчика видео (VideoSubscriberAccount.framework) и конкретно относится к аутентификации для потоковой передачи/воспроизведения видео.

Что касается того, почему он выходит из-под контроля, то это немного сложнее без дополнительной диагностики … нутром реакция будет заключаться в том, что это связано с недавними изменениями iTunes для поддержки унифицированного воспроизведения покупок видео на нескольких платформах. Возможно, он пытается «синхронизировать» ваши покупки видео на разных платформах и терпит неудачу, или просто возникают проблемы с согласованием информации iCloud на них с вашими устройствами.

Я не в США, поэтому даже не могу этим пользоваться. Я никогда не пытался войти в PBS, так что это немного странно.

Я также наблюдаю высокую загрузку ЦП видеоподпиской 10.12.4.
Цитируемая папка появилась в ~/Application Support 1 апреля 2017 года (согласно отметке даты).

Я никогда не подписывался ни на какие видео с помощью iTunes, iPhone или iPad. Насколько мне известно, у меня нет названий видео, которые хотелось бы синхронизировать между устройствами.

Я также наблюдаю, как загрузка ЦП Spotlight увеличивается на несколько минут. Также нечто, называемое coreduetd. После обновления 10.12.4 все эти пожиратели ЦП, похоже, стали свиньями.

Та же проблема после последнего обновления MacOSx.

Никогда раньше не видел этот процесс, а теперь он постоянно использует +33%.

Еще одно приложение-убийца батареи

Та же проблема после последнего обновления MacOSx.

Никогда раньше не видел этот процесс, а теперь он постоянно использует +33%.

Еще одно приложение-убийца батареи

Даг только что сообщил мне об этом сообщении.
У меня возникла та же проблема при использовании его сценария/приложения Multi Item Edit iTunes. Он собирается провести расследование.

Я только что проснулся и увидел ту же проблему в macOS 10.12.5. Никогда не видел его раньше. Я попытался принудительно завершить процесс в мониторе активности, и он только что вернулся. Буду рад любым подсказкам относительно того, что вызывает это на Mac.

Я не знаю, на скольких людей это повлияло, возможно, не так уж и много (я еще не исследовал, но это может быть даже специфично для определенных SMBIOS, это, безусловно, проблема при использовании MacPro6,1 SMBIOS на любая скорость).

Меня мучили очень расплывчатые проблемы типа "работает, но не совсем" с центром внимания и центром уведомлений. Прожектор будет иметь проблемы с индексированием должным образом даже после полного удаления старых данных прожектора, центр уведомлений не запустится автоматически, а само окно прожектора никогда не покажет раскрывающийся список результатов и часто просто истекает время ожидания без возврата результата вообще.

Оказалось, проблема заключалась в полном отсутствии термодатчиков. У меня есть материнская плата Supermicro, и они используют Nuvaton NCT7904D для управления всеми вентиляторами, измерения напряжения, температуры и тому подобного. У этого чипа нет поддержки даже в Windows, а в Linux он почти не поддерживается. Вы, наверное, догадываетесь, как обстоят дела в OS X.

Существует фоновый процесс coreduet, который связан с прожектором, датчиком уведомлений и по какой-то странной причине, кажется, собирает данные телеметрии теплового датчика. Возможно, он делает еще какую-то хрень, но я обещаю вам, что бы это ни было, это не важно.

В любом случае, мы можем просто выгрузить эту неприятность, я разгружаю ее уже пару месяцев и никаких побочных эффектов. Я попытался отключить только аспекты тепловых датчиков, но это не сработало, помогло только полное отключение coreduetd. *пожал плечами*. Если кто-нибудь знает, что происходит с coreduet, или даже что это такое, мне было бы очень интересно узнать.

В любом случае, чтобы отключить его навсегда:

Если вы в будущем разберетесь со своими термодатчиками и провели бессонные ночи, задаваясь вопросом, что волшебному coreduetd не разрешено делать на вашей машине, вы можете снова включить его в любое время с помощью:

Я надеюсь, что это поможет еще 2,5 людям, у которых может возникнуть эта проблема. И я приветствую любую дополнительную информацию, если у кого-то есть. В противном случае мир!

itme001

Я встречаю то же самое, мне понравился твой пост, большое спасибо.
и coreduetd, кажется, также связан с передачей.моя карта wifi+bt находится в пути.поэтому я не знаю, повлияет ли это на передачу.

удивительно, что почти никто не сталкивается с такой же проблемой.

itme001

В любом случае, мы можем просто выгрузить эту неприятность, я разгружаю ее уже пару месяцев и никаких побочных эффектов. Я попытался отключить только аспекты тепловых датчиков, но это не сработало, помогло только полное отключение coreduetd. *пожал плечами*.Если кто-нибудь знает, что происходит с coreduet, или даже что это такое, мне было бы очень интересно узнать.

В любом случае, чтобы отключить его навсегда:

привет.Кажется, я решил это.
в sierra 10.12.6
я использую 2696 v3 18 ядер 36 потоков. кто-то недавний переход с 2696v3 на 1680v3 сказал мне, что проблема решена автоматически, поэтому я думаю, что количество ядер вызывает эту проблему.
Я сократил количество ядер до 16 (ht включен), проблема решена.
Число ядер > 16 приведет к тому, что nvdia не сможет открывать панель каждый раз при загрузке ОС (может вызвать перелистывание хромированной страницы) и вызовет сбой ядра (вызывает зависание прожектора. Не влияет на передачу обслуживания).
люди могут редактировать /System/Library/LaunchDaemons/com.apple.coreduetd.osx.plist, удалять запись о прожекторе, чтобы решить проблему сбоя coreduet, вызванного зависанием прожектора.

Я обновлю до 10.13, чтобы посмотреть, сохраняется ли эта проблема.

itme001

привет.
Я использую ssdtprgen.sh для создания ssdt.aml, если я закрываю два ядра. Нужно ли мне повторно генерировать ssdt.aml?
и есть ли способ (ssdt или dsdt) отключить некоторые ядра процессора?

itme001

хорошо.
я решил это.10.12.6.
Закройте число ядер до 16 ядер (гиперпоточность включена). Регенерируйте ssdt (измените данные ssdtprgen.sh на 16 ядер) и dsdt.все в порядке.
Кажется, в 10.13 таких проблем нет.

метаколлин

Я обновлю до 10.13, чтобы посмотреть, сохраняется ли эта проблема.

Привет, itsme001, это отличная информация, однако я считаю, что проблема с coreduet вызвана именно термодатчиками процессора. Я понятия не имею, почему, черт возьми, handoff/coreduet связан с телеметрией теплового датчика, но это конкретная задача, из-за которой он останавливался. Только Apple знает, что с этим происходит, я полагаю.

Вопрос не в количестве ядер, а в количестве связанных термодатчиков. Я подозреваю, что где-то в коде для coreduet, вероятно, есть жестко запрограммированное ограничение в 16 различных датчиков температуры ядра процессора (потому что, почему бы и нет? По крайней мере, сейчас не существует Mac, который мог бы иметь более 16 различных ядер). температура для отчета). Несмотря на это, что-то, вероятно, лениво жестко запрограммировано на 16, но где-то еще в коде оно будет перечислять столько, сколько сможет найти, и когда это число превысит 16. очень легко придумать всевозможную логику цикла или ситуации, когда это приведет к остановке процесса без сбоя. И, будучи остановленным, что-либо еще, ожидающее этой задачи (или просто другие части кода в исполняемом процессе coreduet), фактически никогда не будет достигнуто.

Гиперпоточность, конечно, не имеет отношения ко всему этому, так как количество термодатчиков остается неизменным.

Проблема действительно решена в версии 10.13, однако проблем с 28 физическими/56 логическими ядрами нет.

Кроме того, графические сбои в хроме вызваны ошибкой драйвера, который некорректно обрабатывает прямую запись в память графического процессора при достаточном количестве потоков. Chrome является тредом (как Crackhead, но для потоков) и будет порождать дополнительные потоки рендеринга в зависимости от доступных ядер. На данный момент это чистое предположение, но, возможно, в драйвере NVidia где-то есть ошибка, которая проявляется только тогда, когда более 16 ядер выполняют запись в память графического процессора. Визуальные сбои, безусловно, кажутся тем, что можно увидеть, если ячейки памяти неправильно управляются мьютексами или что-то в этом роде.

Хорошая новость заключается в том, что обходной путь заключается в том, что запись напрямую в память графического процессора просто невозможна. Вот исправление.

Я пишу это, пока мы разговариваем, используя последнюю версию Chrome Canary с полным аппаратным ускорением и всеми остальными преимуществами webgl и т. д. Я использую его уже несколько дней, в какой-то момент открыл 400 вкладок, и у меня не было ни одного графического сбоя, о котором можно было бы говорить. Опять же, это без ограничения количества ядер. Я рекомендую повторно включить все ядра, которые вы отключили, просто потому, что это слишком много ресурсов ЦП, которые просто не нужно использовать.

В любом случае, из Chrome Canary, если вы заглянете на страницу chrome://gpu, вы увидите точное решение этой проблемы в конце списка:

И просто чтобы увидеть, что все зеленое (а затем и некоторые другие, я намеренно установил пару параметров, чтобы еще больше использовать аппаратное ускорение, что теоретически сделало бы сбои более вероятными, если бы проблема не была полностью устранена):

Прошло почти одиннадцать лет с тех пор, как Apple в последний раз поставляла Mac с одним процессорным ядром, и все ее текущие устройства iOS, watchOS и tvOS теперь имеют два или даже четыре процессорных ядра.

Теперь мы принимаем как должное тот факт, что большее количество ядер означает более высокую производительность, но до Mac OS X 10.6 (август 2009 г.) это часто было не так. С тех пор macOS и другие операционные системы Apple были незаметно преобразованы, чтобы они максимально эффективно использовали несколько ядер, намного лучше работали на мобильных устройствах и реагировали на изменения местоположения, источника питания и даже качества условий локальной сети.< /p>

Большинство лучших книг и сайтов содержат подробные сведения о ядре, его расширениях, вводе-выводе, файловых системах, сетях и многом другом. Но, что удивительно, они на самом деле не объясняют, как на самом деле работают macOS, iOS и т. д. Не сейчас, так как он изменился за последние несколько лет.

Одна из проблем старой модели Mac OS X и нескольких процессоров/ядер заключалась в том, что для получения максимальной отдачи от этих ядер требовался тщательный дизайн приложений для использования потоков/задач/процессов. Сделано хорошо, получилось отлично. Но разработчикам пришлось изрядно потрудиться, чтобы преуспеть, а многим это не удалось. Вы могли наблюдать, как тяжеловесные приложения загружали одно ядро, а остальные ядра почти бездействовали.

Вы могли почувствовать это и в пользовательском интерфейсе: запустите рендеринг или аналогичную сложную задачу, и все остальное начало останавливаться. Когда Time Machine впервые вышла в 2007 году, дела шли лучше, но по-прежнему было разумно не пытаться делать слишком много, когда выполнялось резервное копирование.

Что изменилось за эти годы, так это то, как macOS (и iOS и т. д.) обрабатывают задачи и ядра — механизм, названный Apple Grand Central Dispatch (GCD), который достигает новых высоты в macOS Sierra. Во многих отношениях Сьерра ничем не отличается от Эль-Капитана или Йосемити. Однако посмотрите, что делает GCD, и вы увидите, что он существенно изменился.

По сути, GCD — это диспетчер. Он управляет очередями задач, активируя те, которые больше всего нуждаются в выполнении, и оставляя менее насущные ждать немного дольше. У него есть свои собственные очереди и очереди, которые собираются приложениями. Некоторые из них запускаются в виде прямых очередей, по принципу «первым пришел — первым обслужен», в других используются сложные эвристики для определения относительных приоритетов.

Резервное копирование с помощью Time Machine — наиболее очевидная задача, которой управляет GCD: оно выполняется примерно с часовыми интервалами, но его точное время определяется множеством других факторов. Если ваш Mac очень занят другими делами, когда наступит час, резервное копирование может быть отложено на пять или десять минут. Если все остальное бездействует, резервное копирование начнется почти в ожидаемое время.

Даже в macOS факторы, учитываемые эвристиками GCD, выходят далеко за рамки текущих возможностей. Посмотрите, например, некоторые файлы конфигурации CoreDuet в /System/Library/DuetKnowledgeBase, и вы можете подумать, что имеете дело с iPhone с его функциями голосовой связи, или другим устройством iOS, которое чувствительно к точному изменению местоположения, или его ориентация. Они демонстрируют, насколько GCD распространен во всех продуктах Apple, от настольных компьютеров Mac до Apple Watch.

Итак, как бы увлекательно это ни было, какое отношение это имеет к любому пользователю Mac?

Все больше и больше приложений теперь используют очереди отправки GCD для обработки задач внутри приложения, и все больше и больше служб запускаются не старой системой планирования launchd, а управляются эвристикой GCD. Хотя в большинстве случаев GCD великолепен, у него есть свои проблемы: например, до Sierra 10.12.4 он содержал серьезную ошибку, которая в конечном итоге привела к тому, что он перестал работать должным образом.

Когда простые вещи идут не так, мы знаем, как исправить их настройки, как удалить плохо работающие расширения ядра и настроить параметры LaunchAgent, и часто можем обойти проблемы, которые в противном случае могли бы помешать нам делать то, что нам нужно. Когда с GCD что-то идет не так, мало кто из нас даже знает, как диагностировать проблему, и почти нет инструментов, которые могли бы нам помочь.

Одной из хорошо известных проблем многозадачности и параллелизма является взаимоблокировка, когда одна задача ожидает другую, а другая не может продолжить работу, пока первая задача не будет завершена. GCD не застрахован от взаимоблокировок, и в El Capitan и Sierra возникли некоторые любопытные проблемы, которые выглядят подозрительно, как будто взаимоблокировка могла быть их основной причиной.

Я также начинаю задаваться вопросом, являются ли некоторые из постоянных проблем, с которыми мы столкнулись с отключениями Bluetooth, как в El Capitan, так и в Sierra, результатом проблем в GCD, а не в самих драйверах Bluetooth. Даже сейчас, с Sierra 10.12.4, редко проходит день без того, чтобы мой Magic Trackpad 2 самопроизвольно отключался, а затем снова подключался.

Все это усложняется эвристикой GCD, ее «умной» системой диспетчеризации. При попытке определить и диагностировать проблемы предсказуемость является одним из наиболее важных свойств, но из-за этих сложных эвристик ничто в НОД не следует четким и простым правилам.

Не поймите меня неправильно: я думаю, что эти изменения в macOS (iOS и т. д.) — одни из самых важных, сделанных Apple. Я вижу все меньше и меньше вращающихся пляжных мячей, и GCD позволил Apple провести мощную кампанию как внутри компании, так и со сторонними разработчиками по их устранению. Дни ожидания завершения задач, прежде чем вы сможете приступить к работе, в значительной степени прошли: компьютеры Mac остаются отзывчивыми даже при большой нагрузке. Но устранять проблемы без документации или инструментов чертовски сложно.

Примечание: как вы увидите из длинной серии комментариев ниже, в этой статье и в других местах, я использую название Grand Central Dispatch для описания группы технологий и сервисов, которая намного шире, чем разработчик Apple. документация пятилетней давности. Поскольку Apple до сих пор не опубликовала ссылку на Grand Central Dispatch, невозможно узнать, совпадает ли мое использование с Apple, или подсистемы, такие как DAS и CTS, предназначены для того, чтобы быть частью другой системы. GCD здесь является удобным общим термином для «старого GCD», CTS, DAS и некоторых других связанных битов. Если у вас возникли проблемы с этим, предложите лучшее название.

Самый простой способ проверить производительность системы на Mac — использовать Activity Monitor, встроенное приложение, которое дает вам оперативный обзор жесткого диска, оперативной памяти, процессора и использования сети вашего Mac.

Чтобы получить доступ к монитору активности, перейдите в Finder, Приложения, Утилиты. Нажмите Монитор активности.
Выберите категорию процессов, которую хотите проверить. Вы можете выбрать ЦП, Память, Энергию, Диск, Сеть и Кэш.
Затем можно выбрать объем отображаемой информации и формат. Например:
- Все процессы
- Все процессы Иерархически это позволяет вам видеть отношения родитель/потомок в процессах
- Мои процессы, процессы, принадлежащие вашему аккаунту пользователя macOS®
- Системные процессы, процессы, принадлежащие macOS
- Другие пользовательские процессы, процессы, не принадлежащие пользователю root (учетная запись администратора) или текущему пользователю
- Активные процессы
- Неактивные процессы, спящие процессы
- Оконные процессы, процессы, которые создают окно для действий пользователя, обычно приложения
- Выбранные процессы, процессы, выбранные вами в окне «Монитор активности».
- Приложения за последние 8 часов, приложения, запущенные за последние 8 часов.

Что проверить

Если вы ищете конкретный показатель эффективности, вы можете его найти, но есть некоторые особенности, на которые стоит обратить внимание.

Проверьте процессор на Mac

Вы можете отсортировать панель ЦП по различным столбцам, чтобы увидеть, какая часть ЦП используется каждым приложением. Эта информация может помочь определить процессы, влияющие на производительность. На графике загрузки ЦП показан процент используемых в настоящее время возможностей. Если загрузка ЦП постоянно превышает 60%, вы можете проверить наличие скрытых и фоновых процессов, которые используют много процессорного пространства. Закройте или удалите их, если это возможно.

Проверьте память на Mac

На панели "Память" показано, как используется память. График нагрузки на память иллюстрирует доступность памяти. Если на графике много желтого и красного, возможно, пришло время увеличить объем оперативной памяти на вашем компьютере.

Проверка энергии на Mac

На панели "Энергия" показано как общее энергопотребление, так и энергопотребление каждого открытого приложения. Важный элемент, на который следует обратить внимание, — это приложения, которые не позволяют компьютеру переходить в спящий режим, в столбце «Предотвращение спящего режима». Если вы пытаетесь экономить электроэнергию, когда компьютер не используется, не забудьте закрыть те приложения, которые не позволяют спать.

Проверьте сеть на Mac

На панели «Сеть» показано, сколько данных отправляет или получает компьютер с разбивкой по отдельным приложениям. Если вы следите за тем, сколько данных вы используете, это хорошее место, чтобы узнать, какие приложения используют больше всего данных.

Отслеживание эффективности

Если вы предпочитаете отслеживать производительность в режиме реального времени, вы можете отслеживать загрузку ЦП в фоновом режиме во время работы в других приложениях.

Чтобы открыть окно, выберите "Окно", затем "Загрузка ЦП".

Если вам нужен график информации в Dock, выберите View, Dock Icon и CPU Usage.

Заключение

Apple® предлагает набор мониторов производительности в Activity Monitor. Эти мониторы позволяют отслеживать и, возможно, настраивать производительность вашего компьютера.

© Micron Technology, Inc., 2018. Все права защищены. Информация, продукты и/или технические характеристики могут быть изменены без предварительного уведомления. Ни Crucial, ни Micron Technology, Inc. не несут ответственности за упущения или ошибки в типографике или фотографии. Micron, логотип Micron, Crucial и логотип Crucial являются товарными знаками или зарегистрированными товарными знаками Micron Technology, Inc. Mac, macOS и Apple являются товарными знаками Apple, Inc., зарегистрированными в США и/или других странах. Все прочие товарные знаки и знаки обслуживания являются собственностью соответствующих владельцев.

Читайте также: