Комментарии 101
А если на странице используются какие-то плагины, например, простихосспаде, флэш, их состояние после гибернации превратится в тыкву?
Вообще очень круто, молодцы!
Вообще очень круто, молодцы!
Какие преимущества у этого решения по сравнению с имеющимися у операционной системы файлом подкачки? В обоих случаях данные сбрасываются на диск при недостатке памяти. Только в подкачку попадают действительно редко используемые данные на основе статистики, а вы сохраняете и восстанавливаете вообще все содержимое, что явно только замусоривает физическую память редко используемыми данными.
Ну, возможно, в том, что тут будут выгружаться только неактивные данные. То есть, та вкладка с которой вы работаете в данный момент с большей вероятностью будет работать в быстрой оперативной памяти, а не в медленном файле подкачки.
Ну, возможно, в том, что тут будут выгружаться только неактивные данные.
И в чем отличие с фалом подкачки? Только в том, что файл подкачки более гранулярный и может выгрузить неиспользуемую память даже у текущей вкладки, если она не была нужна какое-то время. То есть файл подкачки в этом смысле эффективнее.
1. В файл подскачки идет память процесса, а там много лишних данных. Наш снепшот занимает в 5-10 раз меньше места. Это быстрее, особенно на HDD.
2. Браузер гораздо лучше, чем ОС, понимает, какой процесс можно освободить.
3. Мы работаем превентивно и не даем системе «уйти в своп».
4. ОС может загрузить из свопа из-за необязательной фоновой активности.
2. Браузер гораздо лучше, чем ОС, понимает, какой процесс можно освободить.
3. Мы работаем превентивно и не даем системе «уйти в своп».
4. ОС может загрузить из свопа из-за необязательной фоновой активности.
3 Мы работаем превентивно и не даем системе «уйти в своп».
Вот это я не совсем понимаю. Для того, чтобы что-то ушло в своп, не обязательно должно не хватать памяти. Windows очень охотно вымывает память приложений при обычной дисковой активности. Это конечно большая проблема для пользователей, но для вас это данность. В результате фоновые вкладки скорее всего и так уже уйдут в своп после первой фоновой проверки антивируса или ежедневной индексации диска. Так что когда действительно понадобится память, вы начнете перекладывать старые вкладки с диска на диск, чем только усугубите ситуацию.
4 ОС может загрузить из свопа из-за необязательной фоновой активности.
Так такую фоновую активность нужно в первую очередь останавливать, а уже потом думать над другими способами оптимизации.
Разница радикальная. Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти и WorkingSet этого процесса сжат, страницы выгружены на диск. При переходе в эту вкладку и пробуждении потоков им требуются страницы, которые лежат в свопе. ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные». И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.
Таким образом с Hibernate нужно прочитать с диска объем X данных и при этом в системе достаточно свободной памяти, WorkingSet других процессов не сжимается. А в обычном случае это запись X*10 + чтение X*10. Т.е. дисковой активности в 10-20(!) раз больше. Пользователи с медленными жесткими дисками это очень хорошо заметят.
Таким образом с Hibernate нужно прочитать с диска объем X данных и при этом в системе достаточно свободной памяти, WorkingSet других процессов не сжимается. А в обычном случае это запись X*10 + чтение X*10. Т.е. дисковой активности в 10-20(!) раз больше. Пользователи с медленными жесткими дисками это очень хорошо заметят.
Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти
Нет, не значит. Вы отвечаете на комментарий, в котором я описываю почему так может случится.
ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные».
То же самое, что и при гибернации.
И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.
Таких страниц (которых нужно освободить) будет ровно столько, сколько нужно реальной памяти, чтобы в ней поместилась вкладка. Но есть отличие: при свопе будут восстановлены только те страницы, которые нужны здесь и сейчас, их может оказаться 50% или меньше. При Hibernate нужно будет восстановить всю память процесса, даже если 80% не нужно для отображения прямо сейчас.
Я полагаю, что главное преимущество использования некого Hibernate в том, что в отличие от поведения ОС, его поведение контролируемо. У вас появляется возможность сохранять то, что вы хотите и как вы хотите, а не насиловать диск записью блоков по пару килобайт. Хотя, естественно, универсальный механизм файла подкачки намного безопаснее с точки зрения разрушения данных.
Поддерживаю тов. homm.
Мысль о том что это статья об отдельной реализации memory manager'а внутри браузера, который работает в ОС, в которой итак есть memory manager, возникает с самого начала и не развеивается до самого конца.
Вопрос который возникает после всего: почему реализовать собственный процесс управления памятью легче, чем помочь уже существующему memory manager'у ОС понять что некоторые области памяти можно отправлять в pagefile в первую очередь (например управляя активностью потоков, частотой использования памяти и при помощи приоритетов), и оставить эту работу ему?
Тут интересно написано про жизнь pagefile.
Мысль о том что это статья об отдельной реализации memory manager'а внутри браузера, который работает в ОС, в которой итак есть memory manager, возникает с самого начала и не развеивается до самого конца.
Вопрос который возникает после всего: почему реализовать собственный процесс управления памятью легче, чем помочь уже существующему memory manager'у ОС понять что некоторые области памяти можно отправлять в pagefile в первую очередь (например управляя активностью потоков, частотой использования памяти и при помощи приоритетов), и оставить эту работу ему?
Тут интересно написано про жизнь pagefile.
На первый взгляд, все дело в размере. Что означает более быструю выгрузку/загрзку и большую жизнь HDD/SDD.
На второй — ручное управление, что опять-таки означает более плавную навигацию. К примеру, из свопа не вылезает первым делом скриншот страницы, а лезут какие-то данные, с ней связанные.
На третий — ну как же это же свой, собственный велосипед! Как хочу, так и курочу :-)
П.с. я не из Яндекса, я мимокрокодил.
На второй — ручное управление, что опять-таки означает более плавную навигацию. К примеру, из свопа не вылезает первым делом скриншот страницы, а лезут какие-то данные, с ней связанные.
На третий — ну как же это же свой, собственный велосипед! Как хочу, так и курочу :-)
П.с. я не из Яндекса, я мимокрокодил.
По-моему никаких противоречий нет? Выгружая страницу в Hibernate, тем самым освобождается вся память, включая своп. А своп, в свою очередь, работает с отдельными страницами памяти, значит эта освободившаяся память может быть использована для более приоритетных страниц, тем самым оптимизируя работу системы в целом.
Что касается загрузки из свопа и выгрузки в Hibernate — работа со свопом и так происходит постоянно (по вашим словам), поэтому вся операция должна занять не больше времени, чем обычная запись на диск. Поправьте меня, если я где-то не прав.
Что касается загрузки из свопа и выгрузки в Hibernate — работа со свопом и так происходит постоянно (по вашим словам), поэтому вся операция должна занять не больше времени, чем обычная запись на диск. Поправьте меня, если я где-то не прав.
Жаль, что мое вопросы выше остались без ответа (
Прошло уже три года. Я полгода, как перешел с хрома на яндекс браузер. И вот теперь я испытываю неудобства от этого. Несколько раз бразуер висиз-за нехватки памяти. Часто закладки крашатся из-за нехватки памяти.
Вероятно время восстановления вкладки несколько быстрее чем при восстановлении своп, особенно при большом огромном количестве вкладок. Поиск нужных оффсетов и восстановление состояния может занимать довольно немало времени. Правда с hibernate яндекса сравнивать не приходилось.
Преимущество в том что не у всех есть файлы подкачки. Например, на моём компе 32GB памяти, и в связи с тем что она редко используется хотя бы наполовину, подкачки нет, но я предпочел бы чтобы Chrome (или другой браузер) не разрастался до нескольких гигабайт — а такое случается если вкладок много, и некоторые текут в фоне (roundcube/proxmox — яркие примеры).
К сожалению, девелоперы браузеров почему-то считают что гибернацию нужно начинать только когда свободной памяти мало — а это часто неправильно, ибо когда её мало вообще — то обычно поздно пить боржоми (браузер не единственный процесс в системе).
Ещё одно преимущество гибернации в приложении — это как раз независимость от файла подкачки — его можно закрыть (с гибернацией), потом открыть и продолжить с точки закрытия.
К сожалению, девелоперы браузеров почему-то считают что гибернацию нужно начинать только когда свободной памяти мало — а это часто неправильно, ибо когда её мало вообще — то обычно поздно пить боржоми (браузер не единственный процесс в системе).
Ещё одно преимущество гибернации в приложении — это как раз независимость от файла подкачки — его можно закрыть (с гибернацией), потом открыть и продолжить с точки закрытия.
НЛО прилетело и опубликовало эту надпись здесь
Ну разумеется. Как типично для современных разработчиков — вместо оптимизации софта сказать нечто в духе «добавьте памяти» или «добавьте своп». Им-то, конечно, лучше знать, как пользователю пользовать.
Вы несёте бред. Подкачка — это стандартный механизм всех ОС начиная с windows 3.1. Именно благодаря подкачке стала возможна истинная многозадачность и сильно упростилась разработка приложений, т.к. каждому приложению больше не нужно писать свой менеджер памяти. Память теперь условно бесконечная.
Ну а то, что вы её отключили — так это ваше дело. Вы может ещё половину экрана закроете картоном и будете кричать, что разработчики совсем обленились, не оптимизируют программы, чтобы на половине экрана были доступны все функции?
Стандартный механизм != гарантированный механизм. Никакая ОС (кроме, возможно, узко специализированных) не гарантирует ни наличия подкачки, ни её размеров. Пока требование наличия подкачки (вообще или определенных размеров) отсутствует для приложений, нужно расчитывать что её нет совсем. Впрочем, приложение с требованиями наличия файла подкачки, скорее всего, отправится в корзину большинством адекватных пользователей.
Приложение не имеет контроля над алгоритмами подкачки, а ОС не имеет понятия о том что является горячими или холодными данными для приложения, простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Приложение может сказать «не выгружать область памяти X» посредством mlock()/VirtualLock() (хотя и в ограниченных пределах), но не может сказать «выгрузить область X немедленно» или «вернуть область X в память и сообщить когда готово» (неявный возврат при обращении == лаг для приложения). Хуже того, выгруженные данные вне контроля приложения, они не сохраняются при завершении приложения, и приложение понятия не имеет, выгружены они или нет на самом деле. Если некоторые данные (вкладка) мне нужны раз в день, но мгновенно — то подкачка только всё испортит, она не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
Насчёт «истинной» многозадачности (не знаю что уж вы имеете в виду под «истинной») — то многозадачность существовала задолго до механизмов подкачки и прекрасно обходится без них и сейчас. Есть масса задач где подкачка вообще явно запрещена (именно в связи с тем что она непредсказуема и неэффективна).
Насчёт своего менеджера памяти — о да, ну конечно не нужно — именно поэтому существует с десяток библиотек а-ля malloc() и сборщиков мусора, и почти каждый крупный проект делает свой. И именно поэтому существуют сотни вариантов сериализации данных и десятки форматов их хранения (не для баз данных), не так ли?
Насчёт половины экрана — во-первых, экран, в отличие от файла подкачки, вещь монолитная и неделимая, если уж он есть, вы вправе расчитывать известное вам разрешение, то он весь ваш. Но тут появляется во-вторых — кто-то додумался до экранов круглой и других форм, и (внезапно) вы даже на это не можете расчитывать (уже почти картонка). И в-третьих, монобровь на некоторых мобильных передаёт вам пламенный привет — это конечно не пол-экрана, но всё же досадное недоразумение в весьма популярном для всяких контролов месте, и нравится вам это или нет, но либо вы это учитываете в своём приложении либо теряете долю пользователей с таким железом.
Так что да — уж извините, но я буду «кричать» — девелоперы должны учитывать реальные системы и реальные потребности пользователей, если они делают продукт не для себя.
В конце концов, если бы файл подкачки был настолько универсальным и единственно правильным («истинным», наверное?) методом — то вопрос гибернации вкладок вообще бы сейчас не обсуждался, и не было бы массы причиндал для этого. Но реальность такова, что он никак не может заменить «нативную» гибернацию, и никакие апологеты механизма подкачки этого не изменят.
Приложение не имеет контроля над алгоритмами подкачки, а ОС не имеет понятия о том что является горячими или холодными данными для приложения, простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Приложение может сказать «не выгружать область памяти X» посредством mlock()/VirtualLock() (хотя и в ограниченных пределах), но не может сказать «выгрузить область X немедленно» или «вернуть область X в память и сообщить когда готово» (неявный возврат при обращении == лаг для приложения). Хуже того, выгруженные данные вне контроля приложения, они не сохраняются при завершении приложения, и приложение понятия не имеет, выгружены они или нет на самом деле. Если некоторые данные (вкладка) мне нужны раз в день, но мгновенно — то подкачка только всё испортит, она не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
Насчёт «истинной» многозадачности (не знаю что уж вы имеете в виду под «истинной») — то многозадачность существовала задолго до механизмов подкачки и прекрасно обходится без них и сейчас. Есть масса задач где подкачка вообще явно запрещена (именно в связи с тем что она непредсказуема и неэффективна).
Насчёт своего менеджера памяти — о да, ну конечно не нужно — именно поэтому существует с десяток библиотек а-ля malloc() и сборщиков мусора, и почти каждый крупный проект делает свой. И именно поэтому существуют сотни вариантов сериализации данных и десятки форматов их хранения (не для баз данных), не так ли?
Насчёт половины экрана — во-первых, экран, в отличие от файла подкачки, вещь монолитная и неделимая, если уж он есть, вы вправе расчитывать известное вам разрешение, то он весь ваш. Но тут появляется во-вторых — кто-то додумался до экранов круглой и других форм, и (внезапно) вы даже на это не можете расчитывать (уже почти картонка). И в-третьих, монобровь на некоторых мобильных передаёт вам пламенный привет — это конечно не пол-экрана, но всё же досадное недоразумение в весьма популярном для всяких контролов месте, и нравится вам это или нет, но либо вы это учитываете в своём приложении либо теряете долю пользователей с таким железом.
Так что да — уж извините, но я буду «кричать» — девелоперы должны учитывать реальные системы и реальные потребности пользователей, если они делают продукт не для себя.
В конце концов, если бы файл подкачки был настолько универсальным и единственно правильным («истинным», наверное?) методом — то вопрос гибернации вкладок вообще бы сейчас не обсуждался, и не было бы массы причиндал для этого. Но реальность такова, что он никак не может заменить «нативную» гибернацию, и никакие апологеты механизма подкачки этого не изменят.
Тогда сразу пишите к браузеру мин. системные требования:
На ОС Win7 x64 — 4 ГБ ОЗУ.
На ОС Win7 x64 — 4 ГБ ОЗУ.
ОС не имеет понятия о том что является горячими или холодными данными для приложения
ОС как раз знает по факту, какие данные являются горячими. А приложение может лишь предполагать, потому что приложения большие и сложные и то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код.
простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Верно. Показатель того, что память можно выгружать — наличие виртуальной памяти и подкачки. А показатель того, что память нужно выгружать — нехватка памяти. Что именно выгружать — вопрос алгоритмов ОС. Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно. Либо мы хотим сами управлять, что выгружать, тогда наш выбор однозадачность. Но что-то я не слышал, чтобы яндекс-браузер можно было загрузить в однозадачном режиме вместо ОС.
подкачка не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
А гибернация знает заранее? )
ОС как раз знает по факту, какие данные являются горячими.
ОС как раз не знает — предполагает. В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные, я хочу их в любой произвольный момент времени в памяти, а не в свопе (даже если я её неделю не трогал) — но ОС может подумать что их можно выгрузить если они длительно не использовались (что она и делает).
то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
А показатель того, что память нужно выгружать — нехватка памяти.
Да ну? Что ж тогда при её использовании максимум на 50% в своп что-то валится? Где ж эта «нехватка»? Причем и в линухе и в вынь, что примечательно. Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу. Это моя система, мне лучше знать когда и кому что отдавать. В конце концов, я специально поставил в два раза больше памяти чем может потребоваться чтобы обходится без подкачки.
Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно.
Я не совсем понимаю — причём тут вообще «многозадачность»? Без подкачки всё отлично работает (если памяти достаточно) — чем её отсутствие мешает «многозадачности»? Количество процессов или потоков не зависит от наличия или отсутствия подкачки, их одновременная работа и взаимодействие тоже.
А гибернация знает заранее?
Да. Потому что я могу поставить на вкладке метку «не трогать» — и её никто не тронет. Или приложение может реализовать свой алгоритм (типа «гибернировать только если месяц не трогали»). Существует масса способов дать хинт приложению — как алгоритмический, так и явный (от пользователя), а использование подкачки — процесс абсолютно независимый от желания и намерений пользователя и/или приложения, его невозможно контролировать (даже на линухе — swappiness мало помогает).
Вы как будто рассматриваете не реализацию гибернации в реальном мире, где уже есть подкачка и планировщик (откровенно не очень хорошего качества), а рассказываете, как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет. У вас подкачки нет, хорошо, вы конечно очень важный пользователь для Яндекс.Браузера, но сомневаюсь, что эту фичу делали для вас одного.
ОС как раз не знает — предполагает.
ОС как раз точно знает, какие страницы использовались в последнее время.
В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные. я хочу их в любой произвольный момент времени в памяти, а не в свопе
И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
Я рад, что вам не приходилось писать приложения больше 100к строк кода. К ожалению, браузеры намного более сложный продукт.
Что ж тогда при её использовании максимум на 50% в своп что-то валится?
Это элементарное логическое утверждение. Из того, что А является причиной для B никак не следует, что других причин у В быть не может. Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.
Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу
Да еще раз, никто сейчас с вами не обсуждает релизацию подкачки в винде и линуксе. Это вообще не тема статьи и не во власти разработчиков браузера. Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное. Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.
Потому что я могу поставить на вкладке метку «не трогать»
Что-то я видимо невнимательно прочитал статью, что не заметил там никаких меток. Опять какой-то придуманный мир?
… как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет
С точки зрения приложения — ему не нужно знать какие ещё есть приложения, ему нужно знать только какие ресурсы ему выделены, а не пытаться взять всё что есть. Если у меня (условно) 8G памяти, я хочу иметь возможность сказать приложению — «у тебя есть 4G, крутись как хочешь». Почему только 4G, это не его дело — и вот тут как раз встроенное управление памятью/гибернацией важно (потому что ОС точно этого не сделает — в рамках установленных ограничений на процесс).
Подобный механизм (ограничение памяти приложения или их группы) встроен в Linux (и похожие системы) изначально (ulimit/cgroup), в Windows есть некий аналог (Job Objects) — и это правильных подход. В реальной же жизни браузер зачем-то ориентируется на свободную память всей системы (как раз «думая» что он один во всей системе) — и это неправильно.
ОС как раз точно знает, какие страницы использовались в последнее время.
Но она не знает когда они понадобятся в следующий раз, и как быстро.
Вообще управление подкачкой в любой ОС очень сферическое в вакууме — несмотря на то что «в среднем» оно делает полезное дело, оно не учитывает (и не может) ряд частных случаев, браузер и его вкладки является одним из них.
И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?
Вероятно, то, что приложению можно явно сказать об этом? Как это реализовано в The Great Suspender, например (хотя и не идеально).
Ещё раз повторюсь — любое приложение лучше чем ОС знает свои потребности (и потребности пользователя), соответственно, лучше справится с управлением выгрузкой. Но посколько ОС средств такого управления не предоставляет (и не гарантирует), то остается только делать всё внутри. Вот если ОС даст возможность приложению сказать «выгрузить эту область памяти» и «загрузить эту и сказать когда готово» — можно будет полноценно это использовать.
И снова — гибернация в приложении позволяет сохранить состояние независимо от ОС, и продолжить в нужный момент (после рестарта или обновления) — Session Buddy является моделью этого (хотя и не посредством гибернации, к сожалению).
Я рад, что вам не приходилось писать приложения больше 100к строк кода.
Одному — не приходилось, в команде — было дело. И можете не верить, но каждый из девелоперов знал (пусть и не в деталях) о взаимодействии модулей, их целях и задачах. При наличии хорошо продуманной архитектуры и наличии соглашений это не так сложно (впрочем, при их отсутствии у вас будет масса других проблем).
Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.
До этого вы говорили про «нехватку памяти». Так или иначе, это ещё одна причина по которой своп стоит выключить (при наличии достаточного количества RAM) — что бы ОС не делала то что она «считает» нужным, хотя это не всегда так.
Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное.
Им не дан этот механизм — я уже сказал выше почему — ни одна из популярных десктопных ОС не гарантирует наличия файла подкачки, и не дает средств контроля над ним. Расчитывать на то что может быть включено, а может быть нет — это как минимум глупо. Требовать включения — ещё глупее, всё равно что требовать наличия SSD вместо абстрактного диска (который может быть в RAM или сетевым и в 100500 раз лучше/быстрее).
Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.
Этот «выдуманный мир» реализован (пусть и не в полной мере) в Vivaldi, например, и также доступен для всех кто использует The Great Suspender (который, кстати, использует встроенные механизмы Chrome) — а это говорит о том что фича нужная. Есть и другие разработки в этом направлении, что тоже говорит о востребованности «выдуманного» мира.
А можете пояснить, как дисковые операции связаны с оперативной памятью процесса? Впервые слышу о таком эффекте. У него есть название?
Не могу пояснить, не понимаю, что вы спросили.
Вот вы писали, и я не вполне понял, о чём речь:
Вы говорите, что дисковая активность одних процессов приводит к вытеснению в подкачку памяти других процессов?
В результате фоновые вкладки скорее всего и так уже уйдут в своп после первой фоновой проверки антивируса или ежедневной индексации диска.
Вы говорите, что дисковая активность одних процессов приводит к вытеснению в подкачку памяти других процессов?
Да, приводит, потому что есть такая штука как дисктовый кеш в оперативной памяти. Даже при достаточной сильной загруженности памяти, ОС все равно старается держать его в районе 20%. Например сейчас у меня на маке он 1,3 Гб из 8, хотя запущено много чего и свободной памяти явно нет. А на винде он сейчас вообще 4,5 Гб из 8, потому что не особо много что запущено.
И вот винда имеет свойство иногда решить (если процессами давно никто не пользуется), что приложения можно бы уже скинуть в своп, а освободившее место занять дисковым кешем.
А где можно на Windows посмотреть его объём?
Если совсем просто и штатными средствами — диспетчер задач, закладка быстродействие.
Или если чуть сложнее и поподробнее: панель управления — администрирование — системный монитор — добавить показатель (плюсик) — раздел память. И там разные показатели работы кэша имеются за которыми можно последить в динамике.
Или если чуть сложнее и поподробнее: панель управления — администрирование — системный монитор — добавить показатель (плюсик) — раздел память. И там разные показатели работы кэша имеются за которыми можно последить в динамике.
Модель браузера предполагает, что несколько табов могут жить под крышей одного процесса. Решение с файлами подкачки хорошее, если 1 таб гарантировано равно один процесс. Но это не так.
Еще я вижу потенциал этой технологии в восстановлении табов после перезагрузки, например.
Вопрос, возможно, не по адресу, но вы наверняка изучали и знаете: разве у Chrome под Android уже не используется подобная технология? Если я правильно помню, он демонстрирует очень уж характерное поведение: когда переходишь на давно не использованную вкладку — она долго восстанавливается, причём успешно восстанавливается даже при отсутствии сети (в метро между станциями) и вместе с текстом, введённым в поле ввода.
Эта технология сохраняет слепок страницы в формате mhtml на диске. Она используется и в Яндекс.Браузере для Android. Ее проблема еще и в том, что теряется состояние JS и Blink. Где-то текст восстановится (если вебмастер постарался), но далеко не везде. Поэтому мы будем экспериментировать с Hibernate и на Android.
Понял, спасибо.
А вы уже проводили сравнительное тестирование быстродействия восстановления из hibernate и из mhtml? (кажется очевидным, что объём данных для hibernate заметно больше — но, может, восстановление из них менее ресурсоёмко? Или получается только размен скорости и места на качество восстановления?)
А вы уже проводили сравнительное тестирование быстродействия восстановления из hibernate и из mhtml? (кажется очевидным, что объём данных для hibernate заметно больше — но, может, восстановление из них менее ресурсоёмко? Или получается только размен скорости и места на качество восстановления?)
Я больше года назад писал в комментариях на GT вопрос: почему до сих пор не морозят процессы вкладок? Говорите, у 5% больше 30 вкладок? Да у моей жены их может быть около сотни. Пока great suspender ей не поставил, 20 Гб оперативки откровенно не хватало.
Теперь более-менее понятно с какими сложностями связана реализация этой идеи.
Теперь более-менее понятно с какими сложностями связана реализация этой идеи.
По поводу оперативки. Пришлось юзать Win7 x64 на 2 ГБ оперативки, использую всегда Хром. Вот там было видно, что после открытия нескольких вкладок старые вкладки перезагружались при переходе на них.
А вот кажется если открыть Мозилу (в довесок к тому Хрому), то хотя бы в ней вкладка открывалась без проблем.
А вот кажется если открыть Мозилу (в довесок к тому Хрому), то хотя бы в ней вкладка открывалась без проблем.
НЛО прилетело и опубликовало эту надпись здесь
Не скажу за все мобильные браузеры, но в Опере похожее поведение. Можно открыть много вкладок (явно больше, чем влезет в ОЗУ), а затем вернуться к ним, даже без интернета.
А что с этой технологией для MacOS
А имеет ли это смысл именно на жестких дисках или каких-нибудь галимых еММС? Подозреваю, что половина ваших виндопользователей сидят на каких-нибудь ноутбуках, где стоит какой-нибудь фрагментированный HDD на 5400 оборотах с энергосберегающими костылями. И им будет все равно, из-за чего все лагает: из-за кошмарных затыках в I/O или перегрузки из сети с нуля.
Скорость HDD, конечно же, влияет. Но есть еще фактор потери информации во вкладках при перезагрузке из сети.
> но это направление в Chromium решили заморозить.
а почему? посчитали излишним костылить еще один планировщик задач + оом-киллер + реализацию подкачки поверх тех, что уже есть в ОС (в 4х ос)?
это не совсем сарказм. выше уже предлагали иные решения, более правильные так же и по-моему мнению. в общем действительно интересно что же по этому поводу подумали в гугле…
а почему? посчитали излишним костылить еще один планировщик задач + оом-киллер + реализацию подкачки поверх тех, что уже есть в ОС (в 4х ос)?
это не совсем сарказм. выше уже предлагали иные решения, более правильные так же и по-моему мнению. в общем действительно интересно что же по этому поводу подумали в гугле…
> Hibernate в среднем экономит более 330 мегабайт памяти
На каждую вкладку? Надо тогда попробовать.
Оно будет отдельным плагином, чтобы в чистый хром/хромиум поставить?
И сразу предложение — приготовили сохранить вкладку — сожмите __перед__ записью на диск, потом читать будет гораздо быстрее и места надо меньше. Ну и с оптимизацией структуры файла именно на быстрое восстановление.
На каждую вкладку? Надо тогда попробовать.
Оно будет отдельным плагином, чтобы в чистый хром/хромиум поставить?
И сразу предложение — приготовили сохранить вкладку — сожмите __перед__ записью на диск, потом читать будет гораздо быстрее и места надо меньше. Ну и с оптимизацией структуры файла именно на быстрое восстановление.
Расскажите пожалуйста ещё, почему вообще современные страницы жрут памяти больше, чем некоторые 3D игры десятилетней давности. Это интересует и озадачивает многих.
Некоторые? Пятилетней? Да недавно как вчера открыл диспетчер хрома и увидел 1.3гб на вкладке мегаплана, на страничке где кроме блока текста и коментариев нет вообще ничерта.
Вот например открыты 3 вкладки Хабра.
Скрин диспетчера
Процессы Хрома тратят 683 МБ оперативки (частный р/н).
Да на таком объеме юзать XP с антивирусом можно было 5 лет назад.
Скрин диспетчера
Процессы Хрома тратят 683 МБ оперативки (частный р/н).
Да на таком объеме юзать XP с антивирусом можно было 5 лет назад.
НЛО прилетело и опубликовало эту надпись здесь
Угу, а если использовать везде short вместо int, то ещё в два раза сэкономить можно память?
Не-не-не, тут вы абсолютно неправы. Текст и изображения на 64-битной машине занимают столько же места, сколько на 32-битной. Так что если приложение на 64-битной машине жрёт памяти вдвое больше — значит, его портировали с 32 бит на 64 задней левой ногой. И на этой ноге был надет ласт. Поверх валенка.
НЛО прилетело и опубликовало эту надпись здесь
Как бы вам сказать… Память расходуется не только под указатели. Более того — память расходуется _в основном_ не под указатели. А удваивается размер именно у указателей (вишенка на торте — компилятор Visual C++: знаете, какой у него размер long для 64-битного кода?)
А текст и изображения в случае браузера — это тот контент, который скачан с сети (и альтернативные его представления, вроде DOM) — и, казалось бы, для Chrome именно они должны занимать основной объём памяти.
P.S. Ещё есть мало влияющая на потребление памяти, но сильно удивляющая меня вещь: почему-то что в Windows, что в MacOS, что в JavaScript-движках представление текста — 16-битовый Unicode (UCS-2 или UTF-16). Казалось бы, использование UTF-8 и место экономит (для ASCII-строк), и делает ненужным разделение API на char и wchar, да и символ всё равно в 16 бит уже не влазит — но нет, упорно держатся за этот странный формат…
А текст и изображения в случае браузера — это тот контент, который скачан с сети (и альтернативные его представления, вроде DOM) — и, казалось бы, для Chrome именно они должны занимать основной объём памяти.
P.S. Ещё есть мало влияющая на потребление памяти, но сильно удивляющая меня вещь: почему-то что в Windows, что в MacOS, что в JavaScript-движках представление текста — 16-битовый Unicode (UCS-2 или UTF-16). Казалось бы, использование UTF-8 и место экономит (для ASCII-строк), и делает ненужным разделение API на char и wchar, да и символ всё равно в 16 бит уже не влазит — но нет, упорно держатся за этот странный формат…
На Windows как раз понятно — там так представляется юникодный текст, и при отрисовке не нужно постоянно перекодировать из utf8 в utf16.
В этом-то плане и на макоси понятно — NSString тоже «внутри» использует именно 16-битное представление. Но, если подумать, смысла в этом никакого. Удобнее было бы сделать основными функциями отрисовки не DrawTextW и т.п., а DrawTextA для UTF-8 (т.е. не DrawTextA реализовать через DrawTextW, а наоборот).
Ну то есть договориться, что юникодный текст представляется, как UTF-8, и избежать лишних перекодировок (ну а перекодировку текста в последовательность codepoints всё равно делать надо, что для UTF-8, что для UTF-16).
Но исторически сложилось, что всё идёт через API для 16-битного юникода…
Ну то есть договориться, что юникодный текст представляется, как UTF-8, и избежать лишних перекодировок (ну а перекодировку текста в последовательность codepoints всё равно делать надо, что для UTF-8, что для UTF-16).
Но исторически сложилось, что всё идёт через API для 16-битного юникода…
Вы видимо не поняли: 1.3гб, 1 (одна) вкладка
На то очень много причин :)
Каждый день нам приходят жалобы, что такой-то сайт занимает очень много памяти.
Да, в большенстве случаев это происходит из-за каких-то проблем на сайте.
Вот я сейчас открыл сайт мегаплана и у меня он занимает 136мб:
Как видно, на сайте есть и видео с ютуба и много JS и прилично картинок.
Но и сами браузеры имеют большой потенциал для оптимизаций, над чем мы и работаем!
PS. Скоро мы расскажем об одной интересной проблеме с GC V8 и как мы смогли ее решить.
Каждый день нам приходят жалобы, что такой-то сайт занимает очень много памяти.
Да, в большенстве случаев это происходит из-за каких-то проблем на сайте.
Вот я сейчас открыл сайт мегаплана и у меня он занимает 136мб:
Как видно, на сайте есть и видео с ютуба и много JS и прилично картинок.
Но и сами браузеры имеют большой потенциал для оптимизаций, над чем мы и работаем!
PS. Скоро мы расскажем об одной интересной проблеме с GC V8 и как мы смогли ее решить.
НЛО прилетело и опубликовало эту надпись здесь
А причем тут сайт? Вы внутри не видели как оно работает. Там технологии на грани фантастики. Они тут нынче решили костыль поставить и ререндерить страницу каждые Нсять секунд. У нас компы в офисе аж завернуло в трубу.
Я вот сейчас залип на вашу картинку кстати, что за профайлер? Не знаю зачем оно мне нужно но блин забавно же)
Это внутренний профилировщик самого браузера. Вот тут подробнее
У меня возможно непривычный вопрос, но… А как в хромо-подобных браузерах заставить вкладки работать на полной мощности все время? Сейчас, например, при переключении явно заметно что вкладка «троттлит».
И есть ли способ ускорить браузер, принудительно отдав ему еще ресурсов?
И есть ли способ ускорить браузер, принудительно отдав ему еще ресурсов?
del
А почему нельзя выгружать из памяти только то, что действительно не нужно на вкладке? Можно же выгрузить всякие библиотеки, стили, красивые мулички, анимации и прочий «дизайн» и оставить текст, формы и поля в них? То есть что в header'e, подцепляется, картинки — вон из памяти, столько места будет. А при возвращени — грузить обратно с диска или интернета (обязательно оставить возможность настроить).
И тогда и статья не превратится в тыкву, и данные из форм не потеряются, и вкладки будут быстрее переключаться
И тогда и статья не превратится в тыкву, и данные из форм не потеряются, и вкладки будут быстрее переключаться
как машине понять что нужно а что нет? если даже изображения могут оказаться упакованными данными веб-приложения?
дополнение The Great Discarder
по умолчанию морозит все, есть белый список. работает очень адекватно, запоминает все введенную инфу, место где читал…
по умолчанию морозит все, есть белый список. работает очень адекватно, запоминает все введенную инфу, место где читал…
24 вкладки сейчас открыто. Подозреваю у многих айтишников 10+ вкладок открыто.
технология Hibernate станет доступна всем пользователям Яндекс
… а в каталоге расширений Chrome уже давно доступно расширение The Great Suspender
Раз разговор зашёл о Хроме и памяти, не могу не спросить вот что:
Пользуюсь обычным Google Chrome и не могу избавиться от проблемы с тем, что своп (Commit size) процесса «Browser» бесконтрольно растёт. В результате на 32-битной ОС браузер со временем крэшится, на 64-бит — начинает жутко тормозить.
Не отслеживал точно, но началось это, по-моему, с «сорок-какой-то» версии. Разные расширения для экономии памяти ставил, они работают, но не оказывают никакого влияния на процесс «Браузер». Помогает только перезапуск.
Вместо тысячи слов, привожу скриншот в состоянии, когда все вкладки засаспенжены с помощью Great Suspender:
P.S.
Не подумайте, что я просто так хочу потянуть время разработчиков браузера или хабравчан, дополнительная проблема в том, что решение не получается загуглить из-за названия процесса. По запросам в духе «google chrome reduce swap size browser process», разумеется, выпадают решения для всего браузера (в основном, те же расширения).
Пользуюсь обычным Google Chrome и не могу избавиться от проблемы с тем, что своп (Commit size) процесса «Browser» бесконтрольно растёт. В результате на 32-битной ОС браузер со временем крэшится, на 64-бит — начинает жутко тормозить.
Не отслеживал точно, но началось это, по-моему, с «сорок-какой-то» версии. Разные расширения для экономии памяти ставил, они работают, но не оказывают никакого влияния на процесс «Браузер». Помогает только перезапуск.
Вместо тысячи слов, привожу скриншот в состоянии, когда все вкладки засаспенжены с помощью Great Suspender:
P.S.
Не подумайте, что я просто так хочу потянуть время разработчиков браузера или хабравчан, дополнительная проблема в том, что решение не получается загуглить из-за названия процесса. По запросам в духе «google chrome reduce swap size browser process», разумеется, выпадают решения для всего браузера (в основном, те же расширения).
Я бы для начала попробовал с помощью memory-infra посмотреть, чтобы примерно понять откуда ноги растут. Это вполне может быть какая-то утечка. Если повторяется более менее стабильно, то стоит отправить багрепорт с примерными шагами
что за вкладка у вас кушает полторы сотни гигабайт трафика?
Привет! Отличная статья!
Вадим, вам случаем не приходилось решать проблему с определением соответствия между процессами и вкладками браузера «снаружи» браузера?
Вадим, вам случаем не приходилось решать проблему с определением соответствия между процессами и вкладками браузера «снаружи» браузера?
Hibernate под себя можно будет настроить?
Подскажите когда Я.браузер перестанет «терять» закрепленные вкладки? Проявляется это следующим образом, есть n закрепленных вкладок (скажем 30), после закрытия и открытия браузера их остается значительно меньше, не считал, но что-то около 10-12. Специальных наблюдения на этот счет не проводил, но косвенно заметил, что такое случае после обновления.
Честно говоря, не слышал о таком раньше. Можете подсказать номер обращения в поддержку из ответного письма. Если не обращались, то желательно написать через «Сообщить о проблеме» в меню.
Честно говоря, не оставлял обращений по это проблеме, так как несколько разочарован ответами Яндекса по обращениям. Если позволите, небольшое лирическое отступление на эту тему. Дважды обращался в ТП (достаточно давно, более 2х лет) и оба раза получил ответ в духе «так и быть и должно». Для примера обращался по поводу использования сервиса Я.ДНС-семейный (тот что блочит клубничку и подобное) сам пользовался этим сервисом и рекомендовал друзьям и знакомым, т.е. пользовался целенаправленно и осознанно (это важно) и вот, спустя какое-то время, замечаю, что сервис блочит не только то, что ему положено блочить, но и другие ресурсы, которые вроде как и не попадают под условия блокировки, например сайт местного авиаперевозчика komiaviatrans.ru(блочился по причине попадания под категорию «порнография», если не ошибаюсь), на котором можно приобрести билеты, сдать, узнать расписание и т.п. и вот такой сайт оказался заблочен. Я обратился в ТП и получил ответ «вероятно, Вы по ошибке пользуетесь нашим сервисом, зайдите в настройки Вашей и сетевой карты и поменяйте ДНС». Это первая рукалицо, Яндекс сам учит пользователей как перестать пользоваться их сервисом. Далее, когда я указал, что я целенаправленно пользуюсь данным сервисом, мне ответили «Сервис должен блочить, он блочит. Что Вас не устраивает?», в третий раз на все мои замечания мне ответили «мы же должны защищать наших пользователей от информации непристойного содержания, даже если она размещена на полезном ресурсе (к слову сказать специально искал и не нашел)», на мои вопрошания почему не блочим контакт ведь там очень много всего непристойного, ответа не последовало. Т.е. никто не попытался разобраться в моих вопросах, не было стандартной отписки «мы передадим кому-нибудь», ничего подобного, просто «так и должно быть». Сейчас написал, как Вы просили.
This 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.
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.
НЛО прилетело и опубликовало эту надпись здесь
Сериализация произвольных С++ классов реализована ещё и в CERN ROOT. Даже были утилиты для описания в XML: GCCXML и genreflex.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера