В ночных сборках Firefox появилась (https://billmccloskey.wordpress.com/2013/12/05/multiprocess-.../) поддержка многопроцессного выполнения, подразумевающего вынос в разные процессы средств формирования интерфейса и обработчиков контента. Процесс отвечающий за интерфейс во многом напоминает базовый однопроцессный вариант Firefox, он формирует окружение браузера на основе XUL, выполняет дополнения, инициирует управление вкладками. Отличие состоит в том, что обработка содержимого вкладки выносится из данного базового процесса в отдельный внешний процесс.
Результат формирования интерфейса и обработки контента формируется в виде слоёв, которые определяют содержимое окна. Например, элементы интерфейса, меню и результат обработки контента определяются в отдельных слоях. Из разных процессов слои передаются в систему отрисовки, которая занимается сведением (композитингом) серии слоёв в единое изображение, которое определяет итоговое содержимое окна браузера.Разделение компонентов для обработки контента и формирования интерфейса в разные процессы, позволяет заметно ускорить работу браузера на многоядерных системах, за счёт организации параллельного выполнения не блокирующих друг-друга операций. Потребление памяти в многопроцессном режиме мало отличается от обычного однопроцессного режима, разница составляет всего около 10 Мб, при этом планируемые оптимизации позволят снизить этот показатель.
Проект по переводу Fierfox на многопроцессную архитектуру, развиваемый под кодовым именем Electrolysis (https://wiki.mozilla.org/Electrolysis), стартовал (http://www.opennet.me/opennews/art.shtml?num=21619) в 2009 году, но в 2011 году был приостановлен (http://www.opennet.me/opennews/art.shtml?num=32323) из-за наличия более простых путей повышения отзывчивости интерфейса (например, оптимизация работы сборщика мусора, дробление длительно выполняемых операций или их выделение в отдельный поток, использования асинхронного ввода/вывода и вынос выполнения плагинов в отдельные процессы), не требующих значительной переработки архитектуры браузера. Спустя два года, кода более простые варианты оптимизаций уже воплощены в жизнь, разработчики вернулись к идее обработки контента и пользовательского интерфейса в разных процессах.
<center><a href="http://billmccloskey.files.wordpress.com/2013/10/e10s-1.png&... src="http://www.opennet.me/opennews/pics_base/0_1386272870.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Новый режим уже доступен в ночных сборках (http://nightly.mozilla.org/) Firefox и может быть активирован через установку переменной browser.tabs.remote в настройках about:config. Разработка пока носит экспериментальный характер и не позволяет использовать некоторые возможности браузера, такие как средства для web-разработчиков, вывод на печать и сохранение страниц. Дополнения в новом режиме ведут себя по разному, некоторые работают нормально, а с некоторыми возникают проблемы. В случае краха процесса, обрабатывающего содержимое вкладок, отвечающий за формирование интерфейса процесс продолжает работу и выводит предупреждение о крахе.<center><a href="http://billmccloskey.files.wordpress.com/2013/10/e10s-2.png&... src="http://www.opennet.me/opennews/pics_base/0_1386272992.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Раздельная обработка вкладок в разных процессах пока не поддерживается, в текущий момент возможна работа только одного процесса обработки контента. В будущем планируется обеспечения поддержки работы нескольких процессов обработки контента (отдельный обработчики для каждой вкладки).Основные преимущества перехода к многопроцессной обработке:
-
Оптимизация для многоядерных процессоров
. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки контента может быть задействовано только одно ядро CPU.
-
Предсказуемое потребление памяти
. В случае выделения памяти разного размера со временем растет фрагментация и остается все больше небольших "дыр" от ранее освобожденных объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока. В случае обработки web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобится в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.-
Производительность
. Достоинством разделения подсистем обработки контента и формирования интерфейса пользователя является повышение отзывчивости бразуера, т.е. повышение скорости реакции на действия пользователя и исключение "подвисаний".-
Защита от сбоев
. В случае выхода за пределы допустимой границы буфера или при возникновении другой внештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме.
-
Повышение безопасности
. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе.URL: https://billmccloskey.wordpress.com/2013/12/05/multiprocess-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=38598
Трудно гуглу держать два браузера.
А что гугл как-то участвует в разработке лисы? Чур столовую не считать
Ну если 80+% процентов дохода мозиллы - это "столовая", то не участвует. Но знаете, мне кажется, что это сомнительный подход.
Это доходы от рекламы, а не просто донат. Не будь гугла, они бы продавали место для поисковой строки другой поисковой системе.
Это какой же? Рамблеру?
у них уже давно нет своего поиска. самое ржачное, что и почты либо уже нет либо со дня на день не будет. ;-)
домигрировались, гг
Кто о чем, а тигра о батхерте...
> Кто о чем, а тигра о батхерте...ну раз диванный онолитег считает что у меня батхерт то доооо, стоит задуматься от чего тот батхерт, от того что рамблер просрал все полимеры несколько лет назад, слив поиск или оттого что сейчас сливает свою почту мылосру. :/
Yandex; Yahoo; Search@mail.ru...
Bing
Chandler Bing
duckducktogo же. Говорят, бабла отваливает немеряно. У разрабов гнома спросите.
Давно уже думаю о проблеме, но не знаю - есть ли возможность отключить отрисовку и выполнение js и флеша на неактивных вкладках? А то мой стиль серфинга - открывать кучу вкладок, и после поочередно знакомиться с содержанием, при более 40 тормозит, те же фишки и ютуб например.
это уже реализовано лет так 5. Фоновым вкладкам JS-коду выделяется 1/1000 времени.
И эти 5 лет лис тормозит, значит не JS единым.
Ну флеш продолжает играть в фоновых вкладках, в нашей "большой" компании криворукие дизайнеры стабильно делают баннер для корп портала отжирающий 100% проца (одно ядро к счастью), официальный браузер IE и там в неактивном окне флеш не рисуется или рисуется с урезаным ФПС и проблемы нет, а в FF нагибает все пока не закроешь... хотя есть Suspend Background Tabs, но он GMail нормально в фоне обновляться не дает.
Думаю, браузеры должны развиваться в направлении сокращения используемых ресурсов, а не наоборот. Меня напрягает, что для конформного серфинга уже нужен современный и мощный многоядерный проц.
> хотя есть Suspend Background Tabs,
> но он GMail нормально в фоне обновляться не дает.в about:config по suspend поискал, по background поискал, по tabs поискал
Suspend Background Tabs нет только у меня? или я чего-то неправильно сделал?
а gmail я даже предпочитаю обновлять простой перезагрузкой страницы, удобно
Дополнение UnloadTab возможно поможет.
Кстати, а где же новый наноинтерфейс? Или это скриншот из Holly, а не Nightly? :D
у ночнушки сейчас австралийский вид из окна... ;)
> у ночнушки сейчас австралийский вид из окна... ;)Австралопитековский :(.
Ну это как бы из-под убунты скриншоты (вон тема иконок — Tango обычное). Там никакого наноинтерфейса отродясь не бывало, зато бывало глобалменю.Кстати, вполне разумно отлаживать многопроцессность именно под никсами — Valgrind там, вся любовь.
Уже есть. Скачай nightly и посмотри сам.
к слову об интерфейсе; а, что это за планета изображена на стартовой картинке?
Планета Mozilla http://planet.mozilla.org/Писали, что нарочно старались избежать сходства с земными материками.
> Оптимизация для многоядерных процессоров.Пока одно ядро возится с браузером, остальные занимаются более полезными вещами, все-таки не браузером единым..
> Предсказуемое потребление памяти.Вроде научился уже лис отдавать память назад. Похоже, скоро опять будет учиться.
> Производительность.Лис, обвешанный плагинами (NoScript, AdBlock, CookieManager, Ghostery, e.t.c.)
на нетбуке тормозит чуть сильнее хрома, но за это - сайтами можно хоть как-то пользоваться.
> Защита от сбоев.
> Повышение безопасности.Ну тут бабка надвое сказала, скорее тут надо движок JS и рендер перебирать.
Итого - надеюсь ещё пару лет из "экспериментальной" ветки проект не вылезет..
> Пока одно ядро возится с браузером, остальные занимаются более полезными вещами, все-таки не браузером единым..На серверах возможно, на десктопе рулит время отзыва интерфейса, юзер не заметит что buildworld занимает на 10 секунд больше в бэкграунде, а вот то, что меню "Букмарки" выпадет с чем-то отличным от плавной элегантности выводит некоторых из себя. И они могут уйти на хром, а терять маркет шэр нельзя, так что Мозилле +1. Одобряю.
Так он и так многопоточный, вполне себе может 4/6 ядер загрузить при обновлении нескольких вкладок, как показывает практика.
>Вроде научился уже лис отдавать память назад.И где-то в 20-ых версиях разучился вновь. :(
> Лис, обвешанный плагинами (NoScript, AdBlock, CookieManager, Ghostery, e.t.c.) на нетбуке тормозит чуть сильнее хрома, но за это - сайтами можно хоть как-то пользоваться.Выдумывай себе проблемы, выдумывай.
Вы знаете, мой рекорд - -39, но я так не переживал...
>> Лис, обвешанный плагинами (NoScript, AdBlock, CookieManager, Ghostery, e.t.c.) на нетбуке тормозит чуть сильнее хрома, но за это - сайтами можно хоть как-то пользоваться.
> Выдумывай себе проблемы, выдумывай.Проблемы, обычно, когда без первых двух в интернет вылезаешь. Да, вот тогда проблемы.
Теперь firefox наконец-то догонит (и обгонит) хром по потреблению памяти и вернется на свое историческое место :)
Наконец то! Уже лет пять мечтаю...а как услышал впервые о планах, так и жду.
Наконец-то
Не прошло и 5 лет! Теперь для каждой вкладки отдельный процесс, и лиса больше не сложится от одной глючной вкладки, не придется рестартить. Это следовало бы сделать 5 лет назад. Но спасибо и на этом...
Боюсь представить, сколько памяти станет жрать фаерфокс на моих 5000 вкладках (сейчас 4,5 ГБ)
У меня хром жрал 1.5 ГБ на двадцати. Интересно, чего удастся добиться мозилловцам?
Вкладки-закладки (Panorama).
Где качать? Или они народ опять обманули
Нашел http://nightly.mozilla.org/
> Где качать? Или они народ опять обманули
>[оверквотинг удален]
> . Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код
> от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в
> случае выполнения разными процессами не могут пересекаться. Современные операционные
> системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется
> доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в
> таком процессе, код злоумышленника будет ограничен в своих возможностях и не
> сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях
> требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе.
> URL: https://billmccloskey.wordpress.com/2013/12/05/multiprocess-.../
> Новость: http://www.opennet.me/opennews/art.shtml?num=38598Дожили, скоро будет отдельный девайс BPU....
> Дожили, скоро будет отдельный девайс BPU....Паршивая идея, но похоже на правду. В соседнем треде вон анонимы настаивали, что JS - не ассемблер. Видимо, зря.
>> Дожили, скоро будет отдельный девайс BPU....
> Паршивая идея, но похоже на правду. В соседнем треде вон анонимы настаивали,
> что JS - не ассемблер. Видимо, зря.Причем овер 95% тяжелого контента- это флеш реклама и прочие свистелки...
А почему нельзя выполнять в одном процессе, но в разных потоках?
Почему нельзя? - можно. Напишите свою многопоточную реализацию, Вам никто не запрещает :).
p.s. Крах потока приводит к краху всего процесса, вместе со всеми остальными потоками.
> Крах потока приводит к краху всего процесса, вместе со всеми остальными
> потоками.Что то есть сомнения в данном утверждении, что вы под крахом потока подразумеваете? Вообще конечно понятно что в современных тоннах кода выловить почему может упасть приложение сложнее чем разделить его на много процессов, но мне всё же кажется более правильной ситуацией когда не происходит уничтожение процесса системой из-за того что в нём происходят необработанные исключения либо из-за того что он лезет куда не положено.
p.s. Вот отловить косяки когда приложение разделено на части, будет вероятно легче.
>> Крах потока приводит к краху всего процесса, вместе со всеми остальными
>> потоками.
> Что то есть сомнения в данном утверждении, что вы под крахом потока
> подразумеваете?AV, Seg.Fault, переполнение стека потока, etc...
в зависимости от платформы/ОС.>Вообще конечно понятно что в современных тоннах кода выловить почему
> может упасть приложение сложнее чем разделить его на много процессов, ноВопрос не в "вылавливании", а в "живучести" остальных процессов.
> мне всё же кажется более правильной ситуацией когда не происходит уничтожение
> процесса системой из-за того что в нём происходят необработанные исключения либо
> из-за того что он лезет куда не положено.А что по вашему должно происходить с процессом, который обратился к памяти по адресу 0x00000000 или любому другому "левому"?
Вы коснулись вопроса архитектуры ОС, зачем оффтопить?> p.s. Вот отловить косяки когда приложение разделено на части, будет вероятно легче.
>p.s. Крах потока приводит к краху всего процесса, вместе со всеми остальными потоками.наверное стоит лечить крахи в первую очередь?
>>p.s. Крах потока приводит к краху всего процесса, вместе со всеми остальными потоками.
> наверное стоит лечить крахи в первую очередь?И в нулевую и во вторую и в третью... очередь стоит, как Вы выразились, "лечить" проблемы в исходном коде.
Критические проблемы у потоков runtime "лечатся" только одним способом - убийством процесса.
А, есть ещё прикольный вариант - Kernel Panic/BSOD/<допишите сами>.
>А почему нельзя выполнять в одном процессе, но в разных потоках?Можно, но тогда из пп.1-4 получилось бы реализовать только первый.
Раньше падало редко, теперь будет чаще; пусть все видят новые сообщения. В хроме песочница сразу была, видимо, он и был примером реализации
Ура! Наконец-то лис будет завешивать не одно ядро, а сразу все!
> Ура!Где в Nightly включить масштаб отображения страниц по умолчанию.
> Где в Nightly включить масштаб отображения страниц по умолчанию.Обычное меню открывается Alt+f и т. п., или включается как панель.
Меню-панель с тремя полосочками (как это объяснять пользователям?!) содержит Preferences.
Открыл 20 вкладок с легкими сайтами в файрфоксе, открыл 10 вкладок с тяжелым флешем в хроме. Конечно хром жрет больше, пойду орать на опеннет!!!!!!
> Открыл 20 вкладокПопробовал browser.tabs.remote в настройках about:config, не успел страницу
открыть вылет.
А так все нормально.
Открыл 15 вкладок в лисе, начал открывать те же самые в хроме - когда дошел до 5, потребление памяти сравнялось.
Он и в текущем виде не плохо пашет. А так будет как хром - хавать, хавать и хавать память. Надеюсь в очередной раз сие заглохнет.
Странно, но у меня все наоборот.
Объясните анониму, почему опять многопроцессная архитектура, а не многотредовая?
Памяти не жалко? Любят придумывать кроссплатформенные IPC-костыли?
> Объясните анониму, почему опять многопроцессная архитектура, а не многотредовая?
> Памяти не жалко? Любят придумывать кроссплатформенные IPC-костыли?Сейчас и тогда (для Unix-подобных ОС) создание процесса - малозатратная операция в отличие от "рукопашной" многотредовой задачи. Межпроцессное взаимодействие в данном случае не такое интенсивное (вкладки между собой не взаимодействуют).
> Сейчас и тогда (для Unix-подобных ОС) создание процесса - малозатратная операция <...>Ключевая проблема в том, что *nix для мозиллы - низкоприоритетное направление. Это изрядно портит стройную картину.
Согласно сабжу под никсы им хочешь, не хочешь, а нужно будет задействовать те сисколы, которые предоставляет ОС. Других то нет.
Так что не всё так плохо.зыж
>часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блокаЭто фактически признание того факта, что ОС с этим справляется куда лучше.
И если такой, не мелкий проект это признаёт, то что говорить о местечковых проектиках?
Фактически именно это и говорил вантузятникам (в том числе и тут), когда они носились с многопоточностью, что эта «панацея» далеко не ото всех болезней. Особенно для серверного ПО, где один поток может положить всю остальную пачку целиком и надёжно.
ага, даже 64-битную версию под никсы не собирают. то ли дело под оффтоп.
Ты сам ответил. Процессную модель проще реализовать кроссплатформено, чем тредную.
По-моему, FF хорош и так. Лишь бы не портили. Последний раз он крешился даже не вспомню когда. Открыто более 100 вкладок (vimperator).
> To be conservative, we’re using only one content process for all web content. To get all of the performance, security, and stability benefits of multiple processes, we’ll need to use multiple content processes.I.e. currently useless.
// b.
fixed: двухпроцессная
Firefox 66
Свободные ядра процессора заканчиваются. Пожалуйста, либо увеличьте число ядер процессора, либо закройте вкладки браузера.
Мне кажется или половина коментов здесь говорит о "многопроцессорности" вместо "многопроцессности"? Если что, речь о threads (потоках-процессах).
Ну всё. Теперь будет жрать память как хром.
Будет. Деваться некуда. А только ли браузеры виноваты? Зашёл на страницу. Огнелис 140мб, ДВБ 130мб. Зашёл на другую. Они сравнялись. Больше половины "заслуг" в пожирании ресурсов нужно отдать сайто-ваятелям.
Про значки сайтов: http://quotes.burntelectrons.org/7164
