Кто-то съел мою память на CI!

Вячеслав Ковалев поделился нюансами потребления памяти 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 — Ответы на вопросы