Сбой графического процессора в долго работающем приложении THREE.js с чистым профилем JavaScript Heap - PullRequest
0 голосов
/ 25 апреля 2018

Наше долговременное приложение THREE.js (24/7) дает сбой после нескольких дней использования.Я собрал стресс-тесты, которые имитируют взаимодействие с пользователем, которые находятся в цикле while(true), и они, похоже, занимают от 3 до 4 дней до сбоя с событием WebGL_Context_Lost, которое обычно указывает на сбой процесса на GPU.

Я хорошо разбираюсь в профилировщике кучи Chrome Dev Tools и провел множество тестов, которые все возвращались без объектов между каждой симуляцией (те же симуляции, описанные выше).

Вот один из снимков экрана, показывающий толькосистемные объекты, оставленные позади (игнорируйте размер первого снимка): enter image description here

В диспетчере задач Chrome объем памяти JavaScript и GPU увеличивается, но стабилизируется (я чувствую, что задержка GCиз-за того, как часто эти операции).Не происходит непрерывного подъема в сторону сбоя, что указывает на утечку.

Версии: Chrome 65-66, Windows 10, THREE.js r91

Вопросы:

  1. Возможно ли, чтобы куча JavaScript была без утечек, но что-то могло просочиться в графический процессор?

  2. Какие инструменты можно использовать дляискать утечки памяти графического процессора?

  3. Можно ли узнать, что именно вызвало WebGL_context_lost?(Хром-логи?)

  4. Кто-нибудь имел дело с этим раньше?

  5. Есть идеи?

Заранее спасибо


ОБНОВЛЕНИЕ:

Симуляция выполнялась с 30-минутными интервалами, когда я снимал снимок кучи, а затем снимок экрана диспетчера задач Chrome (AFAIK Capturing Heap Snapshots также запускает GC).

5: 00 - начальныйСнимок с главного экрана

enter image description here

5: 30

enter image description here

6: 00

enter image description here

6: 30

enter image description here

7ish

enter image description here

8 вечера

enter image description here

Вот запутанная часть: даже после выполнения ручного ГХ память GPU оставалась на уровне ~ 490 МБ, пока я не переключилсявкладки, а затем он вернулся к исходным

enter image description here

Если переключение вкладок очистило память графического процессора обратно к начальным, возможно, проблема заключается вчто Chrome пытается быть слишком умным и не избавляется от объектов графического процессора, что создает нагрузку на машину и в конечном итоге заканчивается памятью?

Примечание: эти тесты выполняются на Intel i5 с графикой Intel Iris540 на последних версиях драйверов (23.20.16.4973 - 2018-02-28)

Мы также видели это на Iris 640 с последними драйверами.

Для тех, кто заинтересован, вот сравнениеснимки кучи в 7:30 и 5: 30:

enter image description here


ОБНОВЛЕНИЕ 2 - похоже на проблему с драйвером

После перезагрузки страницы через 2 минуты после симуляции, графический процессор вылетел с сообщением "Крысы, WebGL попала в ловушку".У памяти не было возможности подняться, поэтому я сомневаюсь, что есть утечка.

Системные журналы Windows содержат предупреждения о том, что графический драйвер перестал работать, что происходит в одно и то же время.

GPU crash and corresponding Windows logs

Метка времени WebGLОшибка потери контекста в Chrome: 10:07:52.938PM

Временная метка проблемы с драйвером системного журнала Windows (я предполагаю, что она округлена): 10:07:53PM

1.Можно ли сказать, что это проблема с драйвером?

2.Убивал ли Chrome процесс с графическим процессором и в журнале процесса в журналах Windows ИЛИ не работал ли драйвер неправильно, что в свою очередь приводило к тому, что Chrome убивал процесс с графическим процессором?

На этом компьютере установлена ​​последняя версия драйвера через Центр обновления Windows,Я собираюсь удалить и обновить с помощью драйвера Intel и повторно запустить тесты.

1 Ответ

0 голосов
/ 08 января 2019

У меня была похожая проблема: Приложение на основе three.js, которое загружает некоторые данные с сервера каждые несколько секунд и отображает их с анимацией. Я должен бежать в течение нескольких дней.

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

Решением, с которым я пришел, было создание HTML-страницы контейнера с двумя iframe элементами, один поверх другого. Затем основное приложение загружается в верхний iframe, затем каждые N минут одно и то же приложение загружается в другой iframe, и они переключаются (переключение видимости)

Предыдущий iframe.src установлен на "". Я храню память GPU в чистоте, и поскольку основное приложение не имеет состояния - на самом деле ничего не заметно.

Надеюсь, это поможет.

...