Вячеслав Ковалев поделился нюансами потребления памяти Android-сборками, с которыми столкнулся во время расследования проблем на CI. Обсудил, почему инструменты профайлинга JVM, такие как Visual VM, не подходят для анализа некоторых процессов: например, aapt2.
О спикере: hазработчик программного обеспечения в команде Speed. Фокусируется на оптимизации производительности и стабильности CI-системы для мобильных приложений.
- 00:00 — Начало
- 00:10 — Вступление
- 01:00 — Android CI в Авито
- 02:12 — Flaky-сборки
- 02:46 — К чему приводит потеря стабильности
- 03:17 — Таблица с Flaky-сборками в рамках дежурства
- 03:58 — Заметили ошибку на дежурстве
- 04:12 — Что за verifyResources Gradle Task
- 05:02 — Avito build trace plugin
- 05:40 — Perfetto Traceviewer — смотрим build.trace
- 06:25 — Хотим гипотез — смотрим код Android Gradle Plugin
- 06:57 — Профилируем потребление памяти JVM-процесса
- 07:53 — Смотрим код verifyResources-таски дальше
- 08:51 — AAPT — Android Asset Packaging Tool
- 09:31 — Используем Docker для сборки Android-приложений
- 10:14 — Что такое cgroups
- 10:40 — У каждого контейнера свой лимит памяти
- 10:55 — Смотрим k8s-метрики для отдельного котейнера
- 11:55 — Как понять, что проблема уйдет, если увеличим память
- 12:27 — Добавили логи ядра, поймали момент воспроизведения ошибки
- 12:50 — Превышение лимита → OOMKiller
- 14:37 — Это касается некоторых других Flaky-проблем
- 14:58 — Что в итоге
- 15:30 — Хотим упреждать такие аварии
- 15:49 — Смотрим в системный монитор во время сборки
- 16:03 — Записываем трейсы с помощью Perfetto
- 16:52 — Добавляем tracing процессов во время сборки
- 17:12 — Смотрим trace
- 17:20 — SQL-запрос, смотрим потребление во время сборки
- 18:23 — Хотим знать, что пришёл OOMKiller
- 18:45 — Финальный итог
- 19:40 — Ответы на вопросы
