Браузеры, основанные на Chromium, создают по процессу на каждую вкладку. У этого подхода множество достоинств. Это и безопасность (изоляция сайтов друг от друга), и стабильность (падение одного процесса не тянет за собой весь браузер), и ускорение работы на современных процессорах с большим количеством ядер. Но есть и минус – более высокое потребление оперативной памяти, чем при использовании одного процесса на всё. Если бы браузеры ничего с этим не делали, то их пользователи постоянно видели бы что-то подобное:
В проекте Chromium борются с потреблением памяти фоновыми вкладками с помощью очистки различных кэшей. Речь не про тот кэш, в котором хранятся картинки загруженных страниц. С ним проблем нет – он живет на жестком диске. В современном браузере много другой закэшированной информации, которая хранится в оперативной памяти.
Также в Chromium уже достаточно давно работают над тем, чтобы останавливать JS-таймеры в фоновых вкладках. Иначе очистка кэшей теряет смысл, т.к. активности в фоновых вкладках их восстанавливают. Считается, что если сайты хотят работать в фоне, то нужно использовать service worker, а не таймеры.
Если эти меры не помогают, то остается только одно – выгрузить из памяти весь процесс рендеринга вкладки. Открытый сайт просто перестает существовать. Если переключиться на вкладку, то начнется загрузка из сети. Если во вкладке было видео на паузе, то оно начнет проигрываться с начала. Если на странице заполнялась форма, то введенная информация может быть утеряна. Если во вкладке работало тяжелое JS-приложение, то понадобится запустить его заново.
Проблема выгрузки вкладок особенно неприятна при отсутствии доступа к сети. Отложили вкладку с Хабром для чтения на борту самолета? Будьте готовы, что полезная статья превратится в тыкву.
Разработчики браузеров понимают, что эта крайняя мера вызывает раздражение у пользователей (достаточно обратиться к поиску, чтобы оценить масштабы), поэтому применяют ее в последний момент. В этот момент компьютер уже тормозит из-за нехватки памяти, пользователи это замечают и ищут альтернативные способы решения проблемы, поэтому, к примеру, у расширения The Great Suspender более 1,4 млн пользователей.
Люди хотят, чтобы браузеры и память экономили, и тормозить при этом не начинали. Для этого вкладки нужно выгружать не в последний момент, а чуть раньше. А для этого нужно перестать терять содержимое вкладок, т.е. сделать процесс экономии незаметным. Но на чем тогда экономить? Круг замкнулся. Но решение нашлось.
Hibernate в Яндекс.Браузере
Многие читатели Хабра уже могли догадаться, что очистить память, но сохранить состояние вкладки вполне возможно, если предварительно выгрузить состояние на жесткий диск. Если по клику восстановить вкладку с жесткого диска, то пользователь не заметит ничего.
Наша команда участвует в разработке проекта Chromium, куда отправляет значительные оптимизирующие правки и новые возможности. Ещё в 2015 году мы обсуждали с коллегами из проекта идею сохранения состояния вкладок на жесткий диск и даже успели внести ряд доработок, но это направление в Chromium решили заморозить. Мы решили иначе и продолжили разработку в Яндекс.Браузере. На это ушло больше времени, чем планировали, но это того стоило. Чуть ниже мы расскажем о технической начинке технологии Hibernate, а пока начнем с общей логики.
Несколько раз в минуту Яндекс.Браузер проверяет количество доступной памяти, и если ее меньше, чем пороговое значение в 600 мегабайт, то в дело вступает Hibernate. Всё начинается с того, что Браузер находит наиболее старую (по использованию) фоновую вкладку. Кстати, в среднем у пользователя открыто 7 вкладок, но у 5% их более 30.
Выгружать из памяти любую старую вкладку нельзя – можно сломать что-то действительно важное. Например, воспроизведение музыки или общение в веб-мессенджере. Таких исключений сейчас 28. Если вкладка не подошла хотя бы по одному из них, то Браузер переходит к проверке следующей.
Если найдена вкладка, которая удовлетворяет требованиям, то начинается процесс ее сохранения.
Сохранение и восстановление вкладок в Hibernate
Любую страницу можно условно разделить на две большие части, связанные с движками V8 (JS) и Blink (HTML/DOM). Рассмотрим небольшой пример:
<html>
<head>
<script type="text/javascript">
function onLoad() {
var div = document.createElement("div");
div.textContent = "Look ma, I can set div text";
document.body.appendChild(div);
}
</script>
</head>
<body onload="onLoad()"></body>
</html>У нас есть некоторое DOM-дерево и небольшой скрипт, который просто добавляет div в body. С точки зрения Blink, эта страница выглядит примерно так:
Давайте посмотрим на связь между Blink и V8 на примере HTMLBodyElement:
Можно заметить, что Blink и V8 имеют разные представления одних и тех же сущностей и тесно связаны друг с другом. Так мы пришли к первоначальной идее – сохранять полное состояние V8, а для Blink хранить лишь HTML-атрибуты в виде текста. Но это было ошибкой, потому что мы потеряли те состояния DOM-объектов, которые хранились не в атрибутах. А еще потеряли состояния, которые хранились не в DOM. Решением этой проблемы было полное сохранение Blink. Но не всё так просто.
Для начала нужно собрать информацию об объектах Blink. Поэтому в момент сохранения V8 мы не только останавливаем JS и делаем его слепок, но и собираем в памяти ссылки на DOM-объекты и прочие вспомогательные объекты, доступные для JS. Мы также проходим по всем объектам, до которых можно дотянуться из объектов Document – корневых элементов каждого фрейма страницы. Так мы собираем информацию обо всем, что важно сохранить. Остается самое сложное – научиться сохранять.
Если посчитать все классы Blink, которые представляют DOM-дерево, а также разные HTML5 API (например, canvas, media, geolocation), то получим тысячи классов. Практически невозможно написать руками логику сохранения всех классов. Но хуже всего то, что даже если так сделать, то это будет невозможно поддерживать, потому что мы регулярно подливаем новые версии Chromium, которые вносят неожиданные изменения в любой класс.
Наш Браузер для всех платформ собирается с помощью clang. Чтобы решить задачу сохранения классов Blink, мы создали плагин для clang, который строит AST (абстрактное синтаксическое дерево) для классов. Например, вот этот код:
class Bar : public foo_namespace::Foo {
struct BarInternal {
int int_field_;
float float_field_;
} bar_internal_field_;
std::string string_field_;
};Превращается в такой XML:
<class>
<name>bar_namespace::Bar::BarInternal</name>
<is_union>false</is_union>
<is_abstract>false</is_abstract>
<decl_source_file>src/bar.h</decl_source_file>
<base_class_names></base_class_names>
<fields>
<field>
<name>int_field_</name>
<type>
<builtin>
<is_const>0</is_const>
<name>int</name>
</builtin>
</type>
</field>
<field>
<name>float_field_</name>
<type>
<builtin>
<is_const>0</is_const>
<name>float</name>
</builtin>
</type>
</field>
</class>
<class>
<name>bar_namespace::Bar</name>
<is_union>false</is_union>
<is_abstract>false</is_abstract>
<decl_source_file>src/bar.h</decl_source_file>
<base_class_names>
<class_name>foo_namespace::Foo</class_name>
</base_class_names>
<fields>
<field>
<name>bar_internal_field_</name>
<type>
<class>
<is_const>0</is_const>
<name>bar_namespace::Bar::BarInternal</name>
</class>
</type>
</field>
<field>
<name>string_field_</name>
<type>
<class>
<is_const>0</is_const>
<name>std::string</name>
</class>
</type>
</field>
</fields>
</class>Дальше другие написанные нами скрипты генерируют из этой информации код на C++ для сохранения и восстановления классов, который и попадает в сборку Яндекс.Браузера.
void serialize_bar_namespace_Bar_BarInternal(
WriteVisitor* writer,
Bar::BarInternal* instance) {
writer->WriteBuiltin<size_t>(instance->int_vector_field_.size());
for (auto& item : instance->int_vector_field_) {
writer->WriteBuiltin<int>(item);
}
writer->WriteBuiltin<float>(instance->float_field_);
}
void serialize_bar_namespace_Bar(WriteVisitor* writer,
Bar* instance) {
serialize_foo_namespace_Foo(writer, instance);
serialize_bar_namespace_Bar_BarInternal(
writer,
&instance->bar_internal_field_);
writer->WriteString(instance->string_field_);
}Всего у нас генерируется код примерно для 1000 классов Blink. Например, мы научились сохранять такой сложный класс как Canvas. В него можно рисовать из JS-кода, задавать множество свойств, устанавливать параметры кисточек для рисования и так далее. Мы сохраняем все эти свойства, параметры и саму картинку.
После успешного шифрования и сохранения всех данных на жесткий диск процесс вкладки выгружается из памяти до тех пор, пока пользователь не вернется на эту вкладку. В интерфейсе, как и раньше, она никак не выделяется.
Восстановление вкладки происходит не мгновенно, но существенно быстрее, чем при загрузке из сети. Тем не менее мы пошли на хитрый ход, чтобы не раздражать пользователей вспышками белого экрана. Мы показываем скриншот страницы, созданный на этапе сохранения. Это помогает сгладить переход. В остальном процесс восстановления похож на обычную навигацию с той лишь разницей, что Браузер не делает сетевой запрос. Он воссоздает структуру фреймов и DOM-деревья в них, а затем подменяет состояние V8.
Записали видео с наглядной демонстрацией того, как Hibernate выгружает и восстанавливает по клику вкладки с сохранением прогресса в JS-игре, введенного в формах текста и положения видео:
Итоги
В ближайшее время технология Hibernate станет доступна всем пользователям Яндекс.Браузера для Windows. Мы также планируем начать экспериментировать с ней в альфа-версии для Android. С ее помощью Браузер экономит память более эффективно, чем раньше. К примеру, у пользователей с большим числом открытых вкладок Hibernate в среднем экономит более 330 мегабайт памяти и не теряет при этом информацию во вкладках, которая остается доступна в один клик при любом состоянии сети. Мы понимаем, что вебмастерам было бы полезно учитывать выгрузку фоновых вкладок, поэтому планируем поддержать Page Lifecycle API.
Hibernate – не единственное наше решение, направленное на экономию ресурсов. Мы не первый год работаем над тем, чтобы Браузер адаптировался под имеющиеся в системе ресурсы. К примеру, на слабых устройствах Браузер переходит в упрощенный режим, а при отключении ноутбука от источника питания – снижает энергопотребление. Экономия ресурсов – большая и сложная история, к которой мы еще обязательно вернемся на Хабре.
Комментарии (89)
homm
20.09.2018 11:35+1Какие преимущества у этого решения по сравнению с имеющимися у операционной системы файлом подкачки? В обоих случаях данные сбрасываются на диск при недостатке памяти. Только в подкачку попадают действительно редко используемые данные на основе статистики, а вы сохраняете и восстанавливаете вообще все содержимое, что явно только замусоривает физическую память редко используемыми данными.
Henryh
20.09.2018 11:45+1Ну, возможно, в том, что тут будут выгружаться только неактивные данные. То есть, та вкладка с которой вы работаете в данный момент с большей вероятностью будет работать в быстрой оперативной памяти, а не в медленном файле подкачки.
homm
20.09.2018 11:54Ну, возможно, в том, что тут будут выгружаться только неактивные данные.
И в чем отличие с фалом подкачки? Только в том, что файл подкачки более гранулярный и может выгрузить неиспользуемую память даже у текущей вкладки, если она не была нужна какое-то время. То есть файл подкачки в этом смысле эффективнее.
Lof Автор
20.09.2018 11:50+31. В файл подскачки идет память процесса, а там много лишних данных. Наш снепшот занимает в 5-10 раз меньше места. Это быстрее, особенно на HDD.
2. Браузер гораздо лучше, чем ОС, понимает, какой процесс можно освободить.
3. Мы работаем превентивно и не даем системе «уйти в своп».
4. ОС может загрузить из свопа из-за необязательной фоновой активности.homm
20.09.2018 12:053 Мы работаем превентивно и не даем системе «уйти в своп».
Вот это я не совсем понимаю. Для того, чтобы что-то ушло в своп, не обязательно должно не хватать памяти. Windows очень охотно вымывает память приложений при обычной дисковой активности. Это конечно большая проблема для пользователей, но для вас это данность. В результате фоновые вкладки скорее всего и так уже уйдут в своп после первой фоновой проверки антивируса или ежедневной индексации диска. Так что когда действительно понадобится память, вы начнете перекладывать старые вкладки с диска на диск, чем только усугубите ситуацию.
4 ОС может загрузить из свопа из-за необязательной фоновой активности.
Так такую фоновую активность нужно в первую очередь останавливать, а уже потом думать над другими способами оптимизации.
drBasic
20.09.2018 13:03Разница радикальная. Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти и WorkingSet этого процесса сжат, страницы выгружены на диск. При переходе в эту вкладку и пробуждении потоков им требуются страницы, которые лежат в свопе. ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные». И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.
Таким образом с Hibernate нужно прочитать с диска объем X данных и при этом в системе достаточно свободной памяти, WorkingSet других процессов не сжимается. А в обычном случае это запись X*10 + чтение X*10. Т.е. дисковой активности в 10-20(!) раз больше. Пользователи с медленными жесткими дисками это очень хорошо заметят.homm
20.09.2018 13:23Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти
Нет, не значит. Вы отвечаете на комментарий, в котором я описываю почему так может случится.
ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные».
То же самое, что и при гибернации.
И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.
Таких страниц (которых нужно освободить) будет ровно столько, сколько нужно реальной памяти, чтобы в ней поместилась вкладка. Но есть отличие: при свопе будут восстановлены только те страницы, которые нужны здесь и сейчас, их может оказаться 50% или меньше. При Hibernate нужно будет восстановить всю память процесса, даже если 80% не нужно для отображения прямо сейчас.
alfred200
21.09.2018 12:22Я полагаю, что главное преимущество использования некого Hibernate в том, что в отличие от поведения ОС, его поведение контролируемо. У вас появляется возможность сохранять то, что вы хотите и как вы хотите, а не насиловать диск записью блоков по пару килобайт. Хотя, естественно, универсальный механизм файла подкачки намного безопаснее с точки зрения разрушения данных.
homm
21.09.2018 12:58Каким образом контролируемое поведение в отрыве от всего остального может помочь? Вы можете например на бумажке карандашом исполнять процессорные инструкции, будете иметь 100% контроль над выполнением, но ускорения программы вы этим конечно же не добьетесь.
Cayp
20.09.2018 23:36Поддерживаю тов. homm.
Мысль о том что это статья об отдельной реализации memory manager'а внутри браузера, который работает в ОС, в которой итак есть memory manager, возникает с самого начала и не развеивается до самого конца.
Вопрос который возникает после всего: почему реализовать собственный процесс управления памятью легче, чем помочь уже существующему memory manager'у ОС понять что некоторые области памяти можно отправлять в pagefile в первую очередь (например управляя активностью потоков, частотой использования памяти и при помощи приоритетов), и оставить эту работу ему?
Тут интересно написано про жизнь pagefile.Ckpyt
21.09.2018 05:44На первый взгляд, все дело в размере. Что означает более быструю выгрузку/загрзку и большую жизнь HDD/SDD.
На второй — ручное управление, что опять-таки означает более плавную навигацию. К примеру, из свопа не вылезает первым делом скриншот страницы, а лезут какие-то данные, с ней связанные.
На третий — ну как же это же свой, собственный велосипед! Как хочу, так и курочу :-)
П.с. я не из Яндекса, я мимокрокодил.
xjesus666christx
20.09.2018 13:46По-моему никаких противоречий нет? Выгружая страницу в Hibernate, тем самым освобождается вся память, включая своп. А своп, в свою очередь, работает с отдельными страницами памяти, значит эта освободившаяся память может быть использована для более приоритетных страниц, тем самым оптимизируя работу системы в целом.
Что касается загрузки из свопа и выгрузки в Hibernate — работа со свопом и так происходит постоянно (по вашим словам), поэтому вся операция должна занять не больше времени, чем обычная запись на диск. Поправьте меня, если я где-то не прав.
domix32
20.09.2018 12:48Вероятно время восстановления вкладки несколько быстрее чем при восстановлении своп, особенно при большом огромном количестве вкладок. Поиск нужных оффсетов и восстановление состояния может занимать довольно немало времени. Правда с hibernate яндекса сравнивать не приходилось.
Tangeman
20.09.2018 15:17Преимущество в том что не у всех есть файлы подкачки. Например, на моём компе 32GB памяти, и в связи с тем что она редко используется хотя бы наполовину, подкачки нет, но я предпочел бы чтобы Chrome (или другой браузер) не разрастался до нескольких гигабайт — а такое случается если вкладок много, и некоторые текут в фоне (roundcube/proxmox — яркие примеры).
К сожалению, девелоперы браузеров почему-то считают что гибернацию нужно начинать только когда свободной памяти мало — а это часто неправильно, ибо когда её мало вообще — то обычно поздно пить боржоми (браузер не единственный процесс в системе).
Ещё одно преимущество гибернации в приложении — это как раз независимость от файла подкачки — его можно закрыть (с гибернацией), потом открыть и продолжить с точки закрытия.nafgne
20.09.2018 16:02+1> подкачки нет
ССЗБTangeman
20.09.2018 17:11Ну разумеется. Как типично для современных разработчиков — вместо оптимизации софта сказать нечто в духе «добавьте памяти» или «добавьте своп». Им-то, конечно, лучше знать, как пользователю пользовать.
homm
21.09.2018 11:27Вы несёте бред. Подкачка — это стандартный механизм всех ОС начиная с windows 3.1. Именно благодаря подкачке стала возможна истинная многозадачность и сильно упростилась разработка приложений, т.к. каждому приложению больше не нужно писать свой менеджер памяти. Память теперь условно бесконечная.
Ну а то, что вы её отключили — так это ваше дело. Вы может ещё половину экрана закроете картоном и будете кричать, что разработчики совсем обленились, не оптимизируют программы, чтобы на половине экрана были доступны все функции?
Tangeman
21.09.2018 13:26Стандартный механизм != гарантированный механизм. Никакая ОС (кроме, возможно, узко специализированных) не гарантирует ни наличия подкачки, ни её размеров. Пока требование наличия подкачки (вообще или определенных размеров) отсутствует для приложений, нужно расчитывать что её нет совсем. Впрочем, приложение с требованиями наличия файла подкачки, скорее всего, отправится в корзину большинством адекватных пользователей.
Приложение не имеет контроля над алгоритмами подкачки, а ОС не имеет понятия о том что является горячими или холодными данными для приложения, простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Приложение может сказать «не выгружать область памяти X» посредством mlock()/VirtualLock() (хотя и в ограниченных пределах), но не может сказать «выгрузить область X немедленно» или «вернуть область X в память и сообщить когда готово» (неявный возврат при обращении == лаг для приложения). Хуже того, выгруженные данные вне контроля приложения, они не сохраняются при завершении приложения, и приложение понятия не имеет, выгружены они или нет на самом деле. Если некоторые данные (вкладка) мне нужны раз в день, но мгновенно — то подкачка только всё испортит, она не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
Насчёт «истинной» многозадачности (не знаю что уж вы имеете в виду под «истинной») — то многозадачность существовала задолго до механизмов подкачки и прекрасно обходится без них и сейчас. Есть масса задач где подкачка вообще явно запрещена (именно в связи с тем что она непредсказуема и неэффективна).
Насчёт своего менеджера памяти — о да, ну конечно не нужно — именно поэтому существует с десяток библиотек а-ля malloc() и сборщиков мусора, и почти каждый крупный проект делает свой. И именно поэтому существуют сотни вариантов сериализации данных и десятки форматов их хранения (не для баз данных), не так ли?
Насчёт половины экрана — во-первых, экран, в отличие от файла подкачки, вещь монолитная и неделимая, если уж он есть, вы вправе расчитывать известное вам разрешение, то он весь ваш. Но тут появляется во-вторых — кто-то додумался до экранов круглой и других форм, и (внезапно) вы даже на это не можете расчитывать (уже почти картонка). И в-третьих, монобровь на некоторых мобильных передаёт вам пламенный привет — это конечно не пол-экрана, но всё же досадное недоразумение в весьма популярном для всяких контролов месте, и нравится вам это или нет, но либо вы это учитываете в своём приложении либо теряете долю пользователей с таким железом.
Так что да — уж извините, но я буду «кричать» — девелоперы должны учитывать реальные системы и реальные потребности пользователей, если они делают продукт не для себя.
В конце концов, если бы файл подкачки был настолько универсальным и единственно правильным («истинным», наверное?) методом — то вопрос гибернации вкладок вообще бы сейчас не обсуждался, и не было бы массы причиндал для этого. Но реальность такова, что он никак не может заменить «нативную» гибернацию, и никакие апологеты механизма подкачки этого не изменят.Victor_koly
21.09.2018 13:43Тогда сразу пишите к браузеру мин. системные требования:
На ОС Win7 x64 — 4 ГБ ОЗУ.
homm
21.09.2018 14:32ОС не имеет понятия о том что является горячими или холодными данными для приложения
ОС как раз знает по факту, какие данные являются горячими. А приложение может лишь предполагать, потому что приложения большие и сложные и то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код.
простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Верно. Показатель того, что память можно выгружать — наличие виртуальной памяти и подкачки. А показатель того, что память нужно выгружать — нехватка памяти. Что именно выгружать — вопрос алгоритмов ОС. Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно. Либо мы хотим сами управлять, что выгружать, тогда наш выбор однозадачность. Но что-то я не слышал, чтобы яндекс-браузер можно было загрузить в однозадачном режиме вместо ОС.
подкачка не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
А гибернация знает заранее? )
Tangeman
21.09.2018 15:19ОС как раз знает по факту, какие данные являются горячими.
ОС как раз не знает — предполагает. В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные, я хочу их в любой произвольный момент времени в памяти, а не в свопе (даже если я её неделю не трогал) — но ОС может подумать что их можно выгрузить если они длительно не использовались (что она и делает).
то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
А показатель того, что память нужно выгружать — нехватка памяти.
Да ну? Что ж тогда при её использовании максимум на 50% в своп что-то валится? Где ж эта «нехватка»? Причем и в линухе и в вынь, что примечательно. Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу. Это моя система, мне лучше знать когда и кому что отдавать. В конце концов, я специально поставил в два раза больше памяти чем может потребоваться чтобы обходится без подкачки.
Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно.
Я не совсем понимаю — причём тут вообще «многозадачность»? Без подкачки всё отлично работает (если памяти достаточно) — чем её отсутствие мешает «многозадачности»? Количество процессов или потоков не зависит от наличия или отсутствия подкачки, их одновременная работа и взаимодействие тоже.
А гибернация знает заранее?
Да. Потому что я могу поставить на вкладке метку «не трогать» — и её никто не тронет. Или приложение может реализовать свой алгоритм (типа «гибернировать только если месяц не трогали»). Существует масса способов дать хинт приложению — как алгоритмический, так и явный (от пользователя), а использование подкачки — процесс абсолютно независимый от желания и намерений пользователя и/или приложения, его невозможно контролировать (даже на линухе — swappiness мало помогает).homm
21.09.2018 18:16Вы как будто рассматриваете не реализацию гибернации в реальном мире, где уже есть подкачка и планировщик (откровенно не очень хорошего качества), а рассказываете, как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет. У вас подкачки нет, хорошо, вы конечно очень важный пользователь для Яндекс.Браузера, но сомневаюсь, что эту фичу делали для вас одного.
ОС как раз не знает — предполагает.
ОС как раз точно знает, какие страницы использовались в последнее время.
В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные. я хочу их в любой произвольный момент времени в памяти, а не в свопе
И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
Я рад, что вам не приходилось писать приложения больше 100к строк кода. К ожалению, браузеры намного более сложный продукт.
Что ж тогда при её использовании максимум на 50% в своп что-то валится?
Это элементарное логическое утверждение. Из того, что А является причиной для B никак не следует, что других причин у В быть не может. Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.
Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу
Да еще раз, никто сейчас с вами не обсуждает релизацию подкачки в винде и линуксе. Это вообще не тема статьи и не во власти разработчиков браузера. Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное. Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.
Потому что я могу поставить на вкладке метку «не трогать»
Что-то я видимо невнимательно прочитал статью, что не заметил там никаких меток. Опять какой-то придуманный мир?
Tangeman
22.09.2018 13:58… как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет
С точки зрения приложения — ему не нужно знать какие ещё есть приложения, ему нужно знать только какие ресурсы ему выделены, а не пытаться взять всё что есть. Если у меня (условно) 8G памяти, я хочу иметь возможность сказать приложению — «у тебя есть 4G, крутись как хочешь». Почему только 4G, это не его дело — и вот тут как раз встроенное управление памятью/гибернацией важно (потому что ОС точно этого не сделает — в рамках установленных ограничений на процесс).
Подобный механизм (ограничение памяти приложения или их группы) встроен в Linux (и похожие системы) изначально (ulimit/cgroup), в Windows есть некий аналог (Job Objects) — и это правильных подход. В реальной же жизни браузер зачем-то ориентируется на свободную память всей системы (как раз «думая» что он один во всей системе) — и это неправильно.
ОС как раз точно знает, какие страницы использовались в последнее время.
Но она не знает когда они понадобятся в следующий раз, и как быстро.
Вообще управление подкачкой в любой ОС очень сферическое в вакууме — несмотря на то что «в среднем» оно делает полезное дело, оно не учитывает (и не может) ряд частных случаев, браузер и его вкладки является одним из них.
И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?
Вероятно, то, что приложению можно явно сказать об этом? Как это реализовано в The Great Suspender, например (хотя и не идеально).
Ещё раз повторюсь — любое приложение лучше чем ОС знает свои потребности (и потребности пользователя), соответственно, лучше справится с управлением выгрузкой. Но посколько ОС средств такого управления не предоставляет (и не гарантирует), то остается только делать всё внутри. Вот если ОС даст возможность приложению сказать «выгрузить эту область памяти» и «загрузить эту и сказать когда готово» — можно будет полноценно это использовать.
И снова — гибернация в приложении позволяет сохранить состояние независимо от ОС, и продолжить в нужный момент (после рестарта или обновления) — Session Buddy является моделью этого (хотя и не посредством гибернации, к сожалению).
Я рад, что вам не приходилось писать приложения больше 100к строк кода.
Одному — не приходилось, в команде — было дело. И можете не верить, но каждый из девелоперов знал (пусть и не в деталях) о взаимодействии модулей, их целях и задачах. При наличии хорошо продуманной архитектуры и наличии соглашений это не так сложно (впрочем, при их отсутствии у вас будет масса других проблем).
Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.
До этого вы говорили про «нехватку памяти». Так или иначе, это ещё одна причина по которой своп стоит выключить (при наличии достаточного количества RAM) — что бы ОС не делала то что она «считает» нужным, хотя это не всегда так.
Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное.
Им не дан этот механизм — я уже сказал выше почему — ни одна из популярных десктопных ОС не гарантирует наличия файла подкачки, и не дает средств контроля над ним. Расчитывать на то что может быть включено, а может быть нет — это как минимум глупо. Требовать включения — ещё глупее, всё равно что требовать наличия SSD вместо абстрактного диска (который может быть в RAM или сетевым и в 100500 раз лучше/быстрее).
Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.
Этот «выдуманный мир» реализован (пусть и не в полной мере) в Vivaldi, например, и также доступен для всех кто использует The Great Suspender (который, кстати, использует встроенные механизмы Chrome) — а это говорит о том что фича нужная. Есть и другие разработки в этом направлении, что тоже говорит о востребованности «выдуманного» мира.
aamonster
20.09.2018 11:39Вопрос, возможно, не по адресу, но вы наверняка изучали и знаете: разве у Chrome под Android уже не используется подобная технология? Если я правильно помню, он демонстрирует очень уж характерное поведение: когда переходишь на давно не использованную вкладку — она долго восстанавливается, причём успешно восстанавливается даже при отсутствии сети (в метро между станциями) и вместе с текстом, введённым в поле ввода.
BarakAdama
20.09.2018 11:56Эта технология сохраняет слепок страницы в формате mhtml на диске. Она используется и в Яндекс.Браузере для Android. Ее проблема еще и в том, что теряется состояние JS и Blink. Где-то текст восстановится (если вебмастер постарался), но далеко не везде. Поэтому мы будем экспериментировать с Hibernate и на Android.
aamonster
20.09.2018 13:09Понял, спасибо.
А вы уже проводили сравнительное тестирование быстродействия восстановления из hibernate и из mhtml? (кажется очевидным, что объём данных для hibernate заметно больше — но, может, восстановление из них менее ресурсоёмко? Или получается только размен скорости и места на качество восстановления?)
SegreyBorovkov
20.09.2018 11:53+2Я больше года назад писал в комментариях на GT вопрос: почему до сих пор не морозят процессы вкладок? Говорите, у 5% больше 30 вкладок? Да у моей жены их может быть около сотни. Пока great suspender ей не поставил, 20 Гб оперативки откровенно не хватало.
Теперь более-менее понятно с какими сложностями связана реализация этой идеи.Victor_koly
20.09.2018 13:32По поводу оперативки. Пришлось юзать Win7 x64 на 2 ГБ оперативки, использую всегда Хром. Вот там было видно, что после открытия нескольких вкладок старые вкладки перезагружались при переходе на них.
А вот кажется если открыть Мозилу (в довесок к тому Хрому), то хотя бы в ней вкладка открывалась без проблем.
YouHim
20.09.2018 18:20У меня была такая же проблема. Вкладки плодятся с огромной скоростью, а закрывать ненужные не доходят руки потому что ярлыки вкладок маленькие и не понятно что можно закрыть, а что нет. Спасением стала панель "окна" в Вивальди. Открываю ее и к своему удивлению из 100 вкладок остаётся от силы штук 5.
Alex_ME
20.09.2018 11:58Не скажу за все мобильные браузеры, но в Опере похожее поведение. Можно открыть много вкладок (явно больше, чем влезет в ОЗУ), а затем вернуться к ним, даже без интернета.
BarakAdama
20.09.2018 12:01Чуть выше ответил. Это технология из мобильного Chromium, которая сохраняет страницы в mhtml. Она сейчас и в Хроме, и в Яндекс.Браузере. Но она сильно ограничена. Теряет состояние JS и Blink. На простых страницах это может быть не так заметно.
Mairon
20.09.2018 12:52А имеет ли это смысл именно на жестких дисках или каких-нибудь галимых еММС? Подозреваю, что половина ваших виндопользователей сидят на каких-нибудь ноутбуках, где стоит какой-нибудь фрагментированный HDD на 5400 оборотах с энергосберегающими костылями. И им будет все равно, из-за чего все лагает: из-за кошмарных затыках в I/O или перегрузки из сети с нуля.
BarakAdama
20.09.2018 13:00+1Скорость HDD, конечно же, влияет. Но есть еще фактор потери информации во вкладках при перезагрузке из сети.
valera5505
20.09.2018 15:24Было бы неплохо добавить какое-то оповещение о том, что страница загружается с жесткого диска, ибо если он медленный, то пользователь может пытаться тыкать в скриншот и не понимать, почему ничего не работает
BarakAdama
20.09.2018 15:34На этот случай добавим прогресс-бар, чтобы было видно, что на странице что-то происходит в этот момент, и она еще не готова.
r0mik
20.09.2018 13:02> но это направление в Chromium решили заморозить.
а почему? посчитали излишним костылить еще один планировщик задач + оом-киллер + реализацию подкачки поверх тех, что уже есть в ОС (в 4х ос)?
это не совсем сарказм. выше уже предлагали иные решения, более правильные так же и по-моему мнению. в общем действительно интересно что же по этому поводу подумали в гугле…BarakAdama
20.09.2018 13:09За них мы ответить не можем. Но проблема с тех пор никуда не ушла.
выше уже предлагали иные решения
Выше было про mhtml и файл подкачки. И то, и другое имеет существенные недостатки.
playnet
20.09.2018 13:14> Hibernate в среднем экономит более 330 мегабайт памяти
На каждую вкладку? Надо тогда попробовать.
Оно будет отдельным плагином, чтобы в чистый хром/хромиум поставить?
И сразу предложение — приготовили сохранить вкладку — сожмите __перед__ записью на диск, потом читать будет гораздо быстрее и места надо меньше. Ну и с оптимизацией структуры файла именно на быстрое восстановление.
igordata
20.09.2018 15:15Расскажите пожалуйста ещё, почему вообще современные страницы жрут памяти больше, чем некоторые 3D игры десятилетней давности. Это интересует и озадачивает многих.
Kwisatz
20.09.2018 16:24Некоторые? Пятилетней? Да недавно как вчера открыл диспетчер хрома и увидел 1.3гб на вкладке мегаплана, на страничке где кроме блока текста и коментариев нет вообще ничерта.
Victor_koly
20.09.2018 22:41Вот например открыты 3 вкладки Хабра.
Скрин диспетчера
Процессы Хрома тратят 683 МБ оперативки (частный р/н).
Да на таком объеме юзать XP с антивирусом можно было 5 лет назад.srhbdv
20.09.2018 22:54-1Ничего, что XP 32х битная, и уже только этот фактор, сокращает в соизмерении потреблении памяти вашего браузера вдвое? И это лишь малый пример некорректности таких вот сравнений, как ваше.
aamonster
21.09.2018 09:32Не-не-не, тут вы абсолютно неправы. Текст и изображения на 64-битной машине занимают столько же места, сколько на 32-битной. Так что если приложение на 64-битной машине жрёт памяти вдвое больше — значит, его портировали с 32 бит на 64 задней левой ногой. И на этой ноге был надет ласт. Поверх валенка.
srhbdv
21.09.2018 09:55При чем тут текст и изображения (когда это вообще ресурсы и не имеют отношения к исполняемому коду приложения, как таковому), когда речь об указателях?
aamonster
21.09.2018 10:41Как бы вам сказать… Память расходуется не только под указатели. Более того — память расходуется _в основном_ не под указатели. А удваивается размер именно у указателей (вишенка на торте — компилятор Visual C++: знаете, какой у него размер long для 64-битного кода?)
А текст и изображения в случае браузера — это тот контент, который скачан с сети (и альтернативные его представления, вроде DOM) — и, казалось бы, для Chrome именно они должны занимать основной объём памяти.
P.S. Ещё есть мало влияющая на потребление памяти, но сильно удивляющая меня вещь: почему-то что в Windows, что в MacOS, что в JavaScript-движках представление текста — 16-битовый Unicode (UCS-2 или UTF-16). Казалось бы, использование UTF-8 и место экономит (для ASCII-строк), и делает ненужным разделение API на char и wchar, да и символ всё равно в 16 бит уже не влазит — но нет, упорно держатся за этот странный формат…hdfan2
21.09.2018 15:18На Windows как раз понятно — там так представляется юникодный текст, и при отрисовке не нужно постоянно перекодировать из utf8 в utf16.
aamonster
21.09.2018 16:01В этом-то плане и на макоси понятно — NSString тоже «внутри» использует именно 16-битное представление. Но, если подумать, смысла в этом никакого. Удобнее было бы сделать основными функциями отрисовки не DrawTextW и т.п., а DrawTextA для UTF-8 (т.е. не DrawTextA реализовать через DrawTextW, а наоборот).
Ну то есть договориться, что юникодный текст представляется, как UTF-8, и избежать лишних перекодировок (ну а перекодировку текста в последовательность codepoints всё равно делать надо, что для UTF-8, что для UTF-16).
Но исторически сложилось, что всё идёт через API для 16-битного юникода…
Lof Автор
20.09.2018 17:55+1На то очень много причин :)
Каждый день нам приходят жалобы, что такой-то сайт занимает очень много памяти.
Да, в большенстве случаев это происходит из-за каких-то проблем на сайте.
Вот я сейчас открыл сайт мегаплана и у меня он занимает 136мб:
Как видно, на сайте есть и видео с ютуба и много JS и прилично картинок.
Но и сами браузеры имеют большой потенциал для оптимизаций, над чем мы и работаем!
PS. Скоро мы расскажем об одной интересной проблеме с GC V8 и как мы смогли ее решить.YouHim
20.09.2018 18:28Извиняюсь за оффтоп. Давно ищу ответ на вопрос. Вдруг вы знаете ответ. У меня вкладка Gmail занимает 500 — 600 мегабайт. В соседнем профиле жены такая же вкладка занимает меньше 100 мб. В чем может быть причина?
hssergey
20.09.2018 19:09В разном составе писем, я думаю. Gmail же предзагружает письма, чтобы сразу они появились если нажать на письмо.
Kwisatz
21.09.2018 00:20А причем тут сайт? Вы внутри не видели как оно работает. Там технологии на грани фантастики. Они тут нынче решили костыль поставить и ререндерить страницу каждые Нсять секунд. У нас компы в офисе аж завернуло в трубу.
Kwisatz
21.09.2018 00:26Я вот сейчас залип на вашу картинку кстати, что за профайлер? Не знаю зачем оно мне нужно но блин забавно же)
springimport
20.09.2018 16:03У меня возможно непривычный вопрос, но… А как в хромо-подобных браузерах заставить вкладки работать на полной мощности все время? Сейчас, например, при переключении явно заметно что вкладка «троттлит».
И есть ли способ ускорить браузер, принудительно отдав ему еще ресурсов?
prs123
20.09.2018 19:01А почему нельзя выгружать из памяти только то, что действительно не нужно на вкладке? Можно же выгрузить всякие библиотеки, стили, красивые мулички, анимации и прочий «дизайн» и оставить текст, формы и поля в них? То есть что в header'e, подцепляется, картинки — вон из памяти, столько места будет. А при возвращени — грузить обратно с диска или интернета (обязательно оставить возможность настроить).
И тогда и статья не превратится в тыкву, и данные из форм не потеряются, и вкладки будут быстрее переключатьсяrPman
20.09.2018 20:41как машине понять что нужно а что нет? если даже изображения могут оказаться упакованными данными веб-приложения?
prs123
20.09.2018 20:44Тут же в статье уже сказано, что нужно сохранить текст, данные форм, место в видео, скорее еще место прокрутки.
Про изображения имел ввиду те, которые явно указываются через соотв. тэг или в стилях прописываются. Поверьте, таких сайтов большинство
3aBulon
20.09.2018 20:28дополнение The Great Discarder
по умолчанию морозит все, есть белый список. работает очень адекватно, запоминает все введенную инфу, место где читал…
isam_os
20.09.2018 21:23-1да наймите уже нормальных программистов чтоли? хватит охреневших распальцованных мальчикоф с конференций…
DoctorMoriarty
21.09.2018 08:24технология Hibernate станет доступна всем пользователям Яндекс
… а в каталоге расширений Chrome уже давно доступно расширение The Great Suspender
Zettabyte
21.09.2018 09:21Раз разговор зашёл о Хроме и памяти, не могу не спросить вот что:
Пользуюсь обычным Google Chrome и не могу избавиться от проблемы с тем, что своп (Commit size) процесса «Browser» бесконтрольно растёт. В результате на 32-битной ОС браузер со временем крэшится, на 64-бит — начинает жутко тормозить.
Не отслеживал точно, но началось это, по-моему, с «сорок-какой-то» версии. Разные расширения для экономии памяти ставил, они работают, но не оказывают никакого влияния на процесс «Браузер». Помогает только перезапуск.
Вместо тысячи слов, привожу скриншот в состоянии, когда все вкладки засаспенжены с помощью Great Suspender:
P.S.
Не подумайте, что я просто так хочу потянуть время разработчиков браузера или хабравчан, дополнительная проблема в том, что решение не получается загуглить из-за названия процесса. По запросам в духе «google chrome reduce swap size browser process», разумеется, выпадают решения для всего браузера (в основном, те же расширения).PurplePowder
21.09.2018 09:47Я бы для начала попробовал с помощью memory-infra посмотреть, чтобы примерно понять откуда ноги растут. Это вполне может быть какая-то утечка. Если повторяется более менее стабильно, то стоит отправить багрепорт с примерными шагами
wizpnz
21.09.2018 12:03Привет! Отличная статья!
Вадим, вам случаем не приходилось решать проблему с определением соответствия между процессами и вкладками браузера «снаружи» браузера?
kaktuss
21.09.2018 12:20Подскажите когда Я.браузер перестанет «терять» закрепленные вкладки? Проявляется это следующим образом, есть n закрепленных вкладок (скажем 30), после закрытия и открытия браузера их остается значительно меньше, не считал, но что-то около 10-12. Специальных наблюдения на этот счет не проводил, но косвенно заметил, что такое случае после обновления.
BarakAdama
21.09.2018 12:37Честно говоря, не слышал о таком раньше. Можете подсказать номер обращения в поддержку из ответного письма. Если не обращались, то желательно написать через «Сообщить о проблеме» в меню.
kaktuss
21.09.2018 13:59Честно говоря, не оставлял обращений по это проблеме, так как несколько разочарован ответами Яндекса по обращениям. Если позволите, небольшое лирическое отступление на эту тему. Дважды обращался в ТП (достаточно давно, более 2х лет) и оба раза получил ответ в духе «так и быть и должно». Для примера обращался по поводу использования сервиса Я.ДНС-семейный (тот что блочит клубничку и подобное) сам пользовался этим сервисом и рекомендовал друзьям и знакомым, т.е. пользовался целенаправленно и осознанно (это важно) и вот, спустя какое-то время, замечаю, что сервис блочит не только то, что ему положено блочить, но и другие ресурсы, которые вроде как и не попадают под условия блокировки, например сайт местного авиаперевозчика komiaviatrans.ru(блочился по причине попадания под категорию «порнография», если не ошибаюсь), на котором можно приобрести билеты, сдать, узнать расписание и т.п. и вот такой сайт оказался заблочен. Я обратился в ТП и получил ответ «вероятно, Вы по ошибке пользуетесь нашим сервисом, зайдите в настройки Вашей и сетевой карты и поменяйте ДНС». Это первая рукалицо, Яндекс сам учит пользователей как перестать пользоваться их сервисом. Далее, когда я указал, что я целенаправленно пользуюсь данным сервисом, мне ответили «Сервис должен блочить, он блочит. Что Вас не устраивает?», в третий раз на все мои замечания мне ответили «мы же должны защищать наших пользователей от информации непристойного содержания, даже если она размещена на полезном ресурсе (к слову сказать специально искал и не нашел)», на мои вопрошания почему не блочим контакт ведь там очень много всего непристойного, ответа не последовало. Т.е. никто не попытался разобраться в моих вопросах, не было стандартной отписки «мы передадим кому-нибудь», ничего подобного, просто «так и должно быть». Сейчас написал, как Вы просили.
neoOpus
21.09.2018 12:20This is a great news, I have always at least 100 tabs open no matter how hard I try and using extension that close them is very annoying and difficult to manage since I have to keep track of a whitelist of the tabs that shouldn't be hibernated to not lose some data which makes me anxious…
I just hope that it will be implanted in English version as well at the same time as the Russian unlike some other features who are still not implanted in the beta yet. while available to Russian since few months ago…
I admire the hard work you guys are doing and I find yandex browser the best in many aspects… just please work a little bit more on the international version or allow us to help somehow by doing the translation or setting the configuration ourselves by modifying the json config files without breaking the signatures and falling back to default russian mode… most of the features still point to yandex.ru instead of yandex.com unfortunately and it takes no time to fix this but it's been months that I am waiting.
Aingis
21.09.2018 13:19+1А мне интересен вопрос безопасности. Открыли так сайт банка (админки популярного сайта, роутера — мало ли интересных интерфейсов), там состояние счёта, куки, токены, чувствительная информация. Вкладка осталась открытой, сохранила на диск своё состояние, и — получается — любая программа с доступом к диску может прочитать эти данные. Это же какой простор для вредоносов! И админские права не нужны, и на больших числах кто-то обязательно да попадётся.
Lof Автор
21.09.2018 19:471. Все слепки шифруются и сжимаются.
2. Мы не сохраняем вкладки интернет-банков.
veprbl
22.09.2018 01:35Сериализация произвольных С++ классов реализована ещё и в CERN ROOT. Даже были утилиты для описания в XML: GCCXML и genreflex.
Sirion
А если на странице используются какие-то плагины, например, простихосспаде, флэш, их состояние после гибернации превратится в тыкву?
Вообще очень круто, молодцы!
Lof Автор
Hibernate просто не станет выгружать из памяти страницы с подобными плагинами, чтобы ничего случайно не сломать.
BigD
Круто… но по сравнению с Chrome браузер все еще очень тормозной, особенно при большом количестве вкладок. И работать с большим количеством вкладок жутко неудобно.