Разработав инструмент для визуализации RAM и zRAM в Android, я обнаружила, что в телефонах происходит активная конкуренция за ресурсы. И если процессу понадобятся ресурсы, которые уже заняты кем-то другим, он отберет их, что может привести к критическим ситуациям и конфликтам оборудования.
Пользовались ли вы когда-нибудь такими утилитами как htop, top, vmstat? Если у вас вообще установлен Linux, то скорее всего да. И они действительно хорошо показывают статистику использования ресурсов в ОС. Я исследовала операционные системы, и мне не хватало понимания того, как реально выглядит физическое адресное пространство: какие конкретно адреса заняты, какие свободны, что происходит, если процессы запрашивают одни и те же адреса, как часто это происходит.
Была гипотеза, что в Android (и в Linux), возникает активная конкуренция за ресурсы. Спойлер из названия статьи: она подтвердилась.
Я разработала приложение, визуализирующее размещение процессов в памяти в телефонах с операционной системой Android. Данные считываются для каждой страницы памяти для выбранного процесса. Эти данные также можно дополнительно обработать. Разработанный инструмент позволяет пользователю исследовать как оперативную память, так и ZRAM, отображать полученную информацию в графическом виде. Пользователь может выбрать процессы из дерева cgroups.
Главное окно приложения выглядит следующим образом. Далее будет рассмотрена именно карта памяти, которая отображается по центру.
Немного теории
Управление памятью в Android является частью функциональности ядра Linux. Ядро имеет полный доступ к системной памяти и позволяет процессам безопасно обращаться к этой памяти по мере необходимости. Приложениям требуется много ресурсов, и поэтому диагностика, анализ и отладка используются для оптимального выделения ресурсов для приложений. Понимание динамики перераспределения памяти может дать гораздо более четкую картину системы. Между тем, мобильные операционные системы имеют больше ограничений, связанных с аппаратным и программным обеспечением, по сравнению с настольными операционными системами.
Управление памятью в ОС Android организовано с помощью страниц размером 4 КБ. Ядро отслеживает состояние каждой страницы физической памяти, представленной в системе.
Я исследовала методы управления памятью в Android и Linux и сравнила доступные инструменты для проверки и мониторинга памяти. Нет инструментов, которые могли бы визуализировать картину. А также трудно интерпретировать числа, поэтому я ввела качественный индикатор и отобразила карту памяти постранично.
apagescan собирает информацию о распределении памяти между несколькими процессами, затем создает снимки памяти и фиксирует динамические изменения памяти. apagescan работает с procFS для чтения любого количества страниц в оперативной памяти, предоставляя информацию о каждой странице, включая флаги present/swapped/dirty и anon/not anon.
Каждая страница может находиться в одном из следующих состояний:
Present / not Present: Текущая страница отображается на страницу в физической памяти. Если страница не present, ее можно свапнуть (переместить) на диск.
Dirty / Clean: Грязные (dirty) страницы - это страницы, которые были изменены, поскольку они были выгружены в физическую память из дисковой памяти и ожидают записи обратно на диск. Чистые (clean) страницы - это страницы, которые не были модифицированы процессом.
Named / Anonymous: Именованные (named) чистые страницы могут быть восстановлены из специального файла. Анонимные (anonymous) страницы поддерживаются разделом подкачки (swap) или физической памятью. Анонимные чистые страницы могут быть восстановлены из /dev/zero.
Также пользователи могут выбирать процессы из cgroups для проверки. cgroups это механизм для группировки процессов на уровне ядра.
Полученные снимки памяти
На Nexus 5 были запущены три приложения, которые использовались в общей сложности в течение двух минут, в то время как apagescan собирал данные с задержкой 0 сек. между измерениями. Было сделано 60 снимков физической памяти. Каждый квадрат (точка) на рисунке это страница в памяти телефона. Черной жирной линией внизу рисунков отделен раздел подкачки.
В эксперименте использовались приложения камеры (синий цвет - 5837 PID), браузера (цвет фуксии - 5307 PID) и галереи (зеленый цвет - 5390 PID). На рис. ниже представлено начальное состояние памяти, когда использовалось приложение браузера, а другие приложения находились в фоновом режиме. Большая часть оперативной памяти занята браузером и гораздо меньше - камерой и галереей. Также отсутствуют страницы в области подкачки.
Во время работы браузера произошли некоторые изменения в отображении памяти, но они стали заметны только тогда, когда приложение браузера перешло в фоновый режим и было выбрано приложение камеры (см. рис. 2). Некоторые страницы были вытеснены страницами камеры, но большинство из них остались на своих местах, а страницы камеры просто заняли свободное место.
На рис. 3-4 показана «конкуренция» между приложениями камеры и галереи (красная область) и процесс вытеснения страниц, когда приложение переходит в фоновый режим (синяя область). То есть на рисунках видно, как разные приложения обращаются к одним и тем же участкам памяти (точки на графиках перекрывают друг друга). И тестирование различных приложений, позволило мне увидеть, что конкуренция за ресурсы происходит достаточно часто. Особенно, если ресурсов не очень много, что, конечно, справедливо для мобильных телефонов.
Выводы
Знание об активной конкуренции за память в Android, может пригодиться как при разработке мобильных приложений, так и областей, связанных с планированием ресурсов в ОС Android (и Linux). Когда один процесс запрашивает ресурсы, которые уже заняты кем-то другим, первый просто отберет их. Это может привести к бесконечному переключению контекста во время нехватки ресурсов, а также к критическим ситуациям и конфликтам оборудования. При этом выявление того, как приложения борются за ресурсы, позволяет оптимизировать систему целиком.
Комментарии (10)
motoroller95
07.11.2021 16:46+8Знание об активной конкуренции за память в Android, может пригодится как при разработке мобильных приложений
Как? Управление памятью это компонент ОС на который вы никак не можете повлиять. Если ваше приложение жрет много памяти то у ОС просто выхода нету кроме как отдать ему максимально возможное кол-во физических страниц, а другие приложения перевести в своп. А потом и ваше приложение в своп уйдет.
Была гипотеза, что в Android (и в Linux), возникает активная конкуренция за ресурсы
Это справедливо не только для Android (и Linux), но и про другие ОС, даже даже больше - в природе вообще конкуренция за ресурсы идет непрерывно.
если процессу понадобятся ресурсы, которые уже заняты кем-то другим, он отберет их
Весьма спорное заявление. Если речь идет за RAM то выше уже писал, если речь идет за какие-то другие аппаратные или программные ресурсы, то тут уже как ОС распорядится. Может и прибить процесс.
Я исследовала методы управления памятью в Android и Linux
А где исследование? Если три картинки это оно и есть, то наверное вы исследовали конкретный кейс, что мол сегодня на этом устройстве ОС решила разбить память вот так, но это не значит что так же будет везде. Внутри ядра есть свои алгоритмы для жанглирования физическими страницами и мапинга их на виртуальное адрестное пространство.
что происходит, если процессы запрашивают одни и те же адреса, как часто это происходит.
Если говорить про физические адреса то процессы их вообще не запрашивают. А виртуальные у каждого свои, что хочу то и творю.
В общем я не понял посыл статьи
ComodoHacker
07.11.2021 17:51-1Интересно. А где приложение-то? Пощупать хочется.
Evengard
08.11.2021 01:00Я так понимаю, речь про вот это: https://github.com/OSLL/apagescan
ComodoHacker
08.11.2021 12:52Наверное, а как вы поняли? В статье ссылки нет.
Evengard
08.11.2021 13:42Загуглил по названию, сравнил скрины в описании, сравнил никнеймы автора статьи и последнего коммитера в репу.
ComodoHacker
08.11.2021 17:15+1Ах, так это была статья-квест! Что ж я сразу не догадался?
Это все к тому, что ссылка должна быть в статье.
Revertis
07.11.2021 19:50+3Очень много ошибок, как будто это бездарный машинный перевод. И слово фуксия усиливает такое ощущение.
Evengard
Кстати, ещё одну интересную вещь заметил, касательно zRAM. По какой-то причине, от zRAMа больше вреда чем пользы при низких значениях swappiness. Телефон начинает кошмарно тормозить при практически любой активности, приложения вместо ухода в zRAM просто молча выгружаются. Телефоном становится вообще почти невозможно пользоваться - всё из-за того что система отчаянно старается ни в коем случае не использовать swap (к которому относится и zRAM) и делает всё что возможно для этого. И, как правило, дефолтное значение swappiness на Андроиде как раз 10, при котором это всё проявляется в полной мере.
Совсем иное дело при swappiness = 100. Да, конечно телефон иногда подтупливает, по сравнению с использоварием просто RAM, но если при низком swappiness телефоном вообще невозможно пользоваться, то при высоком подтупливания иногда только при переключениях между приложениями (очевидно, пока zRAM данные распакуются/запакуются).
Кстати, zRAM на Андроиде удивительно эффективен. Сжатие zRAMом данных превышает, как правило, троекратное!