На прошлой неделе или около того процесс icdd запускался время от времени и, когда он это делал, потреблял огромное количество оперативной памяти (более 7 ГБ). Когда это происходит, мой MacBook Pro по существу перестает работать, пока я не могу открыть Activity Monitor и принудительно завершить процесс.
Я приложил скриншот монитора активности, показывающий icdd, использующий более 7 ГБ оперативной памяти и делающий скачок в памяти.
Кто-нибудь знает, что это за процесс или как я могу предотвратить возникновение этой проблемы каждые 30 минут или около того?
Ответы:
Я работал со старшим техническим консультантом в Apple над этой проблемой более года, а до этого некоторое время работал с другим старшим консультантом. Мы сделали «сбор данных», чтобы отправить его инженерам Apple несколько раз, и несколько раз делали записи экрана, чтобы продемонстрировать, что происходит в Activity Monitor, Image Capture и, в конечном счете, в списке, который icdd поддерживает в / Users / user_name / Library / Application Support / icdd / deviceInfoCache.plist (отображая его в Xcode).
На данный момент, вот моя лучшая оценка того, что происходит:
Процесс icdd (Image Capture Device Database) видит, что сканеры приходят и уходят в загруженной сети. Он пытается сохранить список своих файлов значков в хеш-таблице, которую он также записывает в файл deviceInfoCache.plist, упомянутый выше. Да, это звучит безумно - это ссылки на файлы значков сканеров. Но еще более сумасшедшим является то, что по какой-то причине почти все записи в этом файле указывают на несуществующие файлы .icns. Из нескольких систем, на которые я смотрел, в этом файле было много тысяч записей, но только несколько файлов .icns существовали на одной из машин, и ни одна не существовала на других. Я считаю, что когда этот файл становится большим, icdd тратит много времени, пытаясь проверить наличие записей в файле .plist и изменить файл. Я верю в это по двум причинам. Во-первых, когда я беру свой ноутбук домой, иногда процесс icdd продолжает работать примерно на 100% процессорного времени, но когда я его затем убиваю, он каждый раз возвращается к «нормальному» примерно от 0,0 до 0,1%. Следовательно, я думаю, что иногда я все еще пытаюсь обработать информацию о записях, когда я открываю ее дома. Но когда я убиваю его, находясь в загруженной сети, он часто возвращается почти на 100% сразу. Когда число сканеров, показанных в Захвате изображений, уменьшается (что часто происходит, но по какой-то причине будет периодически расти), icdd в конечном итоге успокоится. И, во-вторых, удаление файла deviceInfoCache.plist приводит к тому, что icdd ведет себя разумно в течение короткого времени - до тех пор, пока количество записей не возрастет снова. Обратите внимание, что icdd хранит копию этих записей в памяти, поэтому, если вы удалите файл из учетной записи пользователя, icdd просто переписывает его немедленно. И, конечно же, вы не можете удалить icdd достаточно долго, чтобы удалить файл, поэтому вам нужно выйти из системы и удалить файл из другой учетной записи администратора через терминал. При повторном входе в icdd файл будет воссоздан, но он будет содержать относительно мало записей и некоторое время будет вести себя хорошо.
Чтобы дать представление о масштабах, инженеры Apple были потрясены, увидев, что у меня было целых 85 сканеров, отображаемых в Image Capture. Однако часто это число устанавливается примерно до 6 в той же системе и в те же периоды времени. Файл deviceInfoCache.plist содержал от 8000 до 12 600 записей в системах, на которые я смотрел, у которых были проблемы с icdd - у меня самая большая, и я считаю, что это перенесено со старой машины, так как у меня были проблемы с icdd с того момента, как я установил свой новый MacBook Pro в 2016-дек. Когда я удалил файл plist, число начальных записей во вновь созданном файле было 44, и в течение нескольких дней использование процессора icdd зависло почти до 0,0%. Тем не менее, после примерно 5 дней в университетском городке, мой plist файл имеет 964 записей, и использование процессора ICDD обычно будет колебаться между 30% и 90% в загруженной сети в университете. Когда я дома, файл plist будет только увеличивать количество записей от 0 до 2 в течение дня. Из 12 600 записей в моем предыдущем файле plist только 2 из них содержат «имя_устройства», остальные содержат «iconPathLocation», все из которых указывают на несуществующие файлы .icns. С текущим списком, все еще есть ровно 2 записи, которые содержат «имя_устройства», а остальные содержат «iconPathLocation», который не существует. все из которых указывают на несуществующие файлы .icns. С текущим списком, все еще есть ровно 2 записи, которые содержат «имя_устройства», а остальные содержат «iconPathLocation», который не существует. все из которых указывают на несуществующие файлы .icns. С текущим списком, все еще есть ровно 2 записи, которые содержат «имя_устройства», а остальные содержат «iconPathLocation», который не существует.
Таким образом, краткосрочное решение состоит в том, чтобы удалить файл plist из другой учетной записи администратора через терминал при выходе из вашей учетной записи пользователя. Надеемся, что теперь эта информация предоставляется инженерам Apple от моего старшего советника, и у инженеров Apple будет достаточно информации, чтобы выяснить, почему icdd действует именно так, и решить проблему. Конечно, было бы полезно, если бы вы могли проверить мое краткосрочное решение и продолжить сообщать о том, что вы нашли в Apple.
источник
Я занимался этой проблемой некоторое время и проверял везде! Это расстраивает ... Наконец-то я нашел ссылку, по которой могу остановить это глупое безумие. Я не уверен, является ли это источником проблемы, но это могло остановить это. Вот шаги:
Оригинальная ссылка: https://havecamerawilltravel.com/photographer/prevent-photos-app-mac-osx
Надеюсь, это поможет.
источник
Я тоже боролся с этой проблемой. Не найдя ответов онлайн и не желая связываться с терминалом, я позвонил в службу поддержки Apple. Первоначально они думали, что мой HD был поврежден (это было - это было исправлено, но не решило проблему). Проблема сохранилась после увеличения моей оперативной памяти. В ответ на интернет-комментарий о поиске сетевого сканера я заметил, что ICDD может сойти с ума только при включенном Wi-Fi. Если я отключусь от Wi-Fi и выйду из ICDD, он не будет перезагружаться и подниматься в ОЗУ или ЦП (пока Wi-Fi не будет включен).
Я снова позвонил в службу поддержки Apple, которая, похоже, устранила проблему, сбросив SMC и NVRAM. Теперь ICDD работает на низком уровне (10-20 МБ), а не потребляет более 10 ГБ ОЗУ. Для этого я добавил ссылки ниже, но я бы порекомендовал обратиться в службу поддержки Apple для решения вашей конкретной проблемы.
Их объяснение того, почему это происходит, было связано с тем, что моя оперативная память была забита или заполнена кешами в Интернете и т. Д. Почему это только что стало очевидным и связано ли это с Сьеррой, я не могу сказать.
Я надеюсь, что это помогает некоторым людям!
Сбросить SMC: https://support.apple.com/en-us/ht201295
Сброс NVRAM: https://support.apple.com/en-us/ht204063
10-15 минут исправить.
Мои характеристики:
источник
Хотя приведенные выше ответы дают лучшие технические данные, я хотел бы добавить общее примечание.
То, с чем мы имеем дело, вероятно, является паршивым программным обеспечением, которое годами несет в себе старые ошибки, которое не было проверено должным образом и, вероятно, никогда не будет исправлено. Вот и все. В последнее десятилетие разработка программного обеспечения Apple постоянно ухудшается, и нам приходится постоянно мириться с такими сценариями.
Обычно сброс таких частей программного обеспечения в их исходное состояние (скажем, путем удаления кэшей и установки файлов, списков .plists или даже сброса их пользовательских настроек по умолчанию) на некоторое время облегчил бы проблему.
Другой способ - сбросить подсистему, связанную с ОС. В этом случае, например,
вы позволите «перезагрузить систему печати», что, возможно, на некоторое время очистит голову icdd, но заставит вас снова настроить среду печати.
И, конечно же, открытие новых записей RADR для Apple может в конечном итоге привлечь их внимание к неисправной подсистеме.
источник