Пользователь пожаловался на MAX: мессенджер нагрузил ядро процессора и активно читал данные с диска

Вокруг настольного клиента MAX снова началось обсуждение технического поведения приложения. Пользователь сообщил, что мессенджер занимал до 94% одного ядра процессора, нагревал ноутбук, расходовал батарею даже при фоновой работе, набрал 33 часа активности и за всё время работы прочитал с диска 1,15 ГБ данных.

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

Из-за этого пьзователей тревожит не только температура ноутбука, но и то, какие данные получает приложение, как работает фоново, какие логи ведет и какие сетевые соединения держит.

Политика конфиденциальности MAX описывает обработку пользовательских и технических данных, cookies и данных, связанных с работой сервиса. Это обычная часть юридической документации цифровой платформы, но она не отвечает на прикладной вопрос: почему конкретный настольный клиент может держать ядро процессора под высокой нагрузкой и читать большой объем данных с диска.

Что могло вызвать такую нагрузку:

• Баг клиента. Например, зависшая синхронизация, повреждённый кэш, зацикленный процесс обновления, пересборка локального индекса сообщений или ошибка обработки вложений.

• Особенности декстопной реализации. Многие современные мессенджеры используют Chromium, Electron, WebView или похожие веб-технологии. Такой клиент может выглядеть как обычное приложение, но внутри работает почти как отдельный браузер. Один зависший JavaScript-процесс способен держать ядро загруженным даже без активной переписки.

• Конфликт с системой. Антивирус, корпоративные политики, драйверы, сетевые фильтры, VPN или прокси могут заставлять приложение постоянно повторять операции, переподключаться, перечитывать кэш или пересоздавать локальные файлы.

• Агрессивная фоновая активность самого приложения. Например, постоянные проверки обновлений, синхронизация медиа, работа уведомлений, поддержание сетевых соединений, отправка диагностических данных или обновление локального состояния.

Без логов нельзя выбрать один сценарий. Но в любом из них высокая нагрузка мессенджера в простое — повод для исправления.

Пользователям в такой ситуации стоит:

• Посмотреть точное имя процесса. В диспетчере задач или системном мониторе нужно понять, грузит систему основной процесс MAX, дочерний WebView-процесс, updater, crash reporter или другой компонент.

• Проверить версию клиента. Приложение стоит обновить из официального источника, затем перезапустить систему. Если проблема появилась после обновления, это тоже важная деталь для баг-репорта.

• Отключить автозапуск. Если MAX не нужен постоянно, лучше убрать его из автозагрузки и закрывать полностью, а не оставлять в трее. На ноутбуке это особенно важно.

• Очистить кэш или переустановить приложение. Повреждённая локальная база или старый кэш могут приводить к зацикленной активности.

• Проверить дисковые обращения. Для Windows подойдёт Process Monitor из набора Sysinternals. Он покажет, к каким путям обращается процесс. Для macOS можно использовать Activity Monitor и fs_usage. Важно смотреть не общий объём чтения, а конкретные файлы и папки.

• Проверить сетевые соединения. На Windows подойдут TCPView или Resource Monitor, на macOS — встроенные инструменты и сетевые мониторы. Это поможет понять, держит ли приложение постоянные соединения и куда обращается.