Мультипроцессовый Firefox

    C января этого года Билл Макклоски вместе с Дэвидом Андерсоном работали над тем, чтобы сделать «Файерфокс» мультипроцессовым, в этом им помогали Том Шустер (evilpie), Фелипе Гомез и Марк Хаммонд. И теперь настал момент, когда они хотели бы узнать мнение сообщества о проделанной работе.

    В «Файерфоксе» всегда использовалась однопроцессовая модель построения. Интерес к изменениям в области распараллеливания подстегнул выход браузера «Хром», в нём использовались один процесс для интерфейса и отдельные процессы для работы с контентом веб-страниц. (Тем не менее за шесть месяцев до «Хрома» несколько процессов начал использовать «Интернет эксплорер 8».) Вскоре, примеру «Хрома» последовали и некоторые другие браузеры, «Мозилла» начала проект Electrolysis для адаптации движка «Гекко» к использованию нескольких процессов.

    Что вынуждает «Мозиллу» переключаться на подобную модель построения своего браузера? В первую очередь это производительность и отзывчивость. Основной целью является уменьшение подвисания (jank), проявляющегося при стандартных операциях — загрузке особенно крупной страницы, наборе текста в веб-форме или прокрутке перегруженной элементами страницы.

    Отзывчивость сегодня является несколько более важной, чем производительность. Часть работ была произведена в рамках проекта Snappy. Основными задачами являлись:

    • Перемещение длинных операций в отдельный поток, чтобы главный процесс сохранял отзывчивость.
    • Реализация асинхронного ввода-вывода таким образом, чтобы главный процесс не был заблокирован дисковыми операциями.
    • Разбиение длинных операций на части с event loop между ними. Примером подобного является параллельный сбор мусора.

    Простейшие из этих задач уже были выполнены, сейчас остались наиболее трудные.

    Другой необходимостью является безопасность. Сейчас, после обнаружения незакрытого бага в «Файерфоксе» злоумышленник может выполнить произвольный код на машинах пользователей. Для решения проблем безопасности используется множество техник и приёмов, но самым эффективным остаётся запуск кода в «песочнице».

    Однако, размещение текущей однопроцессовой архитектуры «Файерфокса» в «песочнице» не представляется эффективным: режим песочницы лишь не даёт процессу выполнять действия, которые он делать не должен, а текущая организация «Файерфокса» (особенно, с множеством дополнений) требует широкого доступа к сети и файловой системе. Мультипроцессовый «Файерфокс» будет обеспечивать работу каждого из процессов веб-контента в режиме песочницы с глубокими ограничениями, что, как надеются разработчики, позволит уменьшить количество уязвимостей в браузере. Контроль за доступом к файловой системе будет производиться главным процессом.

    Кроме того, разработчики пытались повысить стабильность «Огненной лисы», даже несмотря на то, что «Файерфокс» остаётся самым стабильным браузером в мире. Вместо падения целого браузера будет падать лишь процесс, ответственный за конкретную вкладку или элемент.

    Уже сейчас можно попробовать посмотреть, что получилось. Для этого достаточно скачать ночную сборку браузера и установить параметр browser.tabs.remote равным true. Разработчики настойчиво рекомендуют создать новый профиль. about:memory уже отображает потребление для отдельных процессов.

    Так выглядит окно мультипроцессного «Файерфокса». Подчёркнутое название вкладки отражает то, что её контент обрабатывается в отдельном процессе.



    Так падает отдельная вкладка.



    Первый вопрос, который возникает у большинства, связан с потреблением оперативной памяти. Пользователи убеждены, что больше процессов значит больше занятой памяти. Разработчики обещают ряд оптимизаций и внедрение определённых видов кэша, общих для нескольких процессов. Если в одном из них существуют какие-либо данные, записанные одним процессом, другой процесс сможет проверить их наличие и использовать данные из этого кэша вместо создания новых в своей области памяти. Подобная модель позволит как повысить безопасность, так и сохранить некоторое быстродействие.

    С использованием бенчмарка MemBench и после открытия 50 вкладок потребление памяти в сравнении с обычной однопроцессовой версией возросло всего лишь на 10 мегабайт (с 974 мегабайт до 984 мегабайт). С течением времени эта разница станет минимальной.

    На данный момент остаётся неизвестным, когда мультипроцессовый «Файерфокс» достигнет стадии релиза — перед разработчиками стоит слишком много работы. Детали новой архитектуры отражены в публикации Билла Макклоски.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 64

      +26
      >в этом им помогали Том Шустер

      Мне кажется, над Fx уже давно стоило поработать человеку с такой фамилией.
        +3
        Т. е. с фамилией «Сапожников»?
        +15
        позволит усложнить поиск уязвимостей в браузере

        Мне одному кажется, что лучше его облегчить с целью их закрытия?
          +3
          Наверное, имелось ввиду «усложнить использование найденных уязвимостей». Но кто его знает… =)
          +1
          Подчеркивание есть, а дополнительных процессов не вижу, Linux.
          Посмотрим, когда заработает.
          • UFO just landed and posted this here
              +2
              Считаю необходимым процитировать оригинал:
              Собрала операционка все браузеры и строго говорит: Предупреждаю! Любого, кто будет чрезмерно жрать память, сразу буду бить по наглой рыжей морде!
                +15
                С появлением хрома, эта шутка звучит странно :)
                  +5
                  К сожалению это так. Chrome это единственный браузер выжирающий ВСЮ память на компьютере по своим соображениям. Сейчас я хоть на FF спасаюсь, ибо он даже гипотетически не может отъесть больше 2 ГБ, а на практике не отъедает даже более 1, при этом видно, что он убирает неиспользуемые страницы из памяти (видимо на диск скидывает), если и тут введут этот ад с мультипроцессностью, я уже и не знаю, что буду делать :( Иногда, при написании статей, для Chrome не хватает 8 ГБ установленной на компе памяти, и это, ИМХО, фейл, а тот же набор вкладок в FF отжирает около 1 ГБ, и при этом ничего не тормозит, а с Chrome cистема уже колом встаёт :(
                    +1
                    некропостинг, но все же… сжирает 2,7 Гб смело ;)
                      +1
                      Так FF уже тоже мультипроцессорный вроде как :( Пока думаю «решить проблему» втыканием в IDE слот CF карты через переходник и переносом туда файла подкачки, но если честно потихоньку хочется убивать… сначала процессы, потом людей ^_^
            • UFO just landed and posted this here
                +4
                Это разница. Сравнивали потребление однопроцессорной версии с многопроцессорной.
                  0
                  Ну у меня фф со старта жрет 700 мб с 25 открытых вкладок.
                  –7
                  Давно пора, аж стыдно за Firefox было последние пару лет
                    +25
                    С чего бы?

                    — Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
                    — Плагины и так давно запускаются в отдельных процессах.
                    — Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
                    — Тормоза тоже убрали в рамках проекта «Snappy»

                    Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
                      +6
                      Иногда Firefox зависает на какой нибудь странице и всё. Ничего нельзя сделать кроме как ждать или выгрузить приложение целиком. Возможность принудительно закрыть только одну вкладку была бы отличным решением.
                        +3
                        Безопасность процессов-песочниц — не мифическая. В Хроме даже инжектнув свой код в процесс вкладки ты фиг что с ним сделаешь — ни к диску, ни к другим процессам, ни к сети доступа нет. Сидишь в аквариуме и глазками только моргаешь. Процесс лисы имеет все привилегии, безопасности на уровне ОС в нём нет никакой.
                          +1
                          Вопрос в том, что заинжектить код в процесс браузера практически невозможно. Для этого есть две возможности: JS и плагины. Плагины и так в отдельном процессе-песочнице уже много лет. А с JS-ом все очень сложно. Базовая идея: подобрать такой код на JavaScript, чтобы при JIT-компиляции результирующий машинный код делал то, что хочется атакующему. Задача эта сложная, и живых примеров подобных атак даже в «лабораторных» условиях еще не создано.
                            +3
                            Для этого есть две возможности: JS и плагины

                            Я бы не был так категоричен. Очень редко, но бывают уязвимости парсеров html, css или библиотек для работы с изображениями и др.
                          –2
                          Насчёт памяти, сравнивая с Оперой, не вижу результатов этих усилий.
                        +10
                        Первый вопрос, который возникает у большинства, связан с потреблением оперативной памяти. Пользователи убеждены, что больше процессов значит больше занятой памяти.

                        Я всеми руками за нововведение – главное чтобы потом не стало как в хроме, 10 подпроцессов при 50-ти вкладках и «он уже лёг ногами по направлению взрыва и накрылся простынёй»
                          +2
                          А я вот на FF уже только потому, что Chrome, как бы у него там с защитой вкладок было лучше/хуже, тупо не умеет переключать табы по Ctrl+Tab.

                          Это я к тому, что соревнования браузеров ведутся уже давно, но, сделай хромовцы Ctrl+Tab, это был бы аргумент посильнее всяких там «многих процессов» :)
                            +1
                            Спасибо за подсказку, работает (Chrome 31.0.1650.57), а я раньше использовал только ctrl-1 2..8 и 9. :)
                              +3
                              Это что-то конкретно у вас с ним не то. У меня переключение работает как в Убунте, так и на Маке.
                                +6
                                Хм… Надо было написать подробнее:

                                я предпочитаю, чтобы, если у меня открыты 20 вкладок, но я работаю с двумя (переключаюсь попеременно между), то каждое нажатие Ctrl+Tab переносило бы меня в предыдущую вкладку. Т.е. нажал Ctrl+Tab, отпустил, нажал Ctrl+Tab — вижу при этом только две последние.

                                А Хром при любом нажатии Ctrl+Tab дальше по кругу отправляет, т.е. все 20 вкладок по очереди.

                                В Firefox для таких целей можно приделать плагин, а вот Хром комбинацию Ctrl+Tab не дает ни на что повесить — посему народ извращается, делая Ctrl+Q и прочие комбинации, которые близко к Ctrl+Tab. Близко — но не Ctrl+Tab, сами понимаете.
                                  +3
                                  Так понял. Мне как-то удобнее гонять по кругу, а назад через Ctrl+Shift+Tab.
                                    +2
                                    странно, у меня FF последней версии, но Ctrl+Tab работает по кругу
                                      +4
                                      Я лично использую en.design-noir.de/mozilla/ctrl-tab/, вроде то же можно включить в настройках, но я не искал долго.

                                      В Хроме же даже плагин не помогает, нельзя там на эту комбинацию клавиш забиндиться…
                                        +1
                                        Большое спасибо! К такому удобному переходу между используемыми вкладками привык в продуктах JetBrains. Надо будет обязательно попробовать плагин.
                                          +3
                                          Можно выставить browser.ctrlTab.previews в true, при переключении табов будут рисоваться превьюшки, и побочным эффектом будет как раз порядок переключения.
                                            +2
                                            За что и люблю Хабр! ;)

                                            Спасибо!
                                          +5
                                          Tab Mix Plus позволяет настроить массу всякого, связанного с вкладками, в том числе и это.
                                            +2
                                            От этого комбайна пришлось избавиться: он умеет слишком много, а это не всегда хорошо во всех отношениях оказывается. Перешел на «Ctrl-Tab» — тот делает именно что надо.

                                            Теперь попробую рекомендованный выше подход, выставить browser.ctrlTab.previews в true — не люблю обрастать плагинами.
                                      +2
                                      Раньше в chrome удобнее было Ctrl + -> и Ctrl + < — , а потом сделали как везде по Ctrl + Tab и Ctrl + Shift + Tab :(, если первое ещё юзабельно, то второе сочетание уже не так удобно, да и возможности быстро щёлкнуть вперёд — назад тоже не стало.
                                      0
                                      Мне интересно с низкоуровневой точки зрения. Чем процессы лучше потоков? Лучше управляются ОС? Или быстродействие повысится за счёт разнесения вкладок на разные процессы? А почему не потоки? Вот сейчас у меня в запущенной в винде последней лисе 58 потоков, так что при желании она загрузит все 4 ядра. Значит, мы не теряем производительность за из-за того, что всё работает на одном ядре.
                                      У меня сейчас в лисе открыто около 150 вкладок (оставим в стороне вопросы как, зачем и почему), большинство из них не подгружены и висят поскольку постольку. При этом лиса отъедает 0.45-10% процессора. А что будет, если на каждую хотя бы подгруженную (около 15 из 150 сейчас) вкладку будет по процессу? А если все 150? Ладно, что та же нагрузка будет распределена по процессам, но мы получаем оверхед на переключения контекста.
                                      Открываю Comodo Dragon (вариант хрома), 5 вкладок, 7 процессов + мастер-процесс, итого 8. Они в сумме генерируют около тысячи дополнительных смен контекста в секунду! При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
                                        +10
                                        1. Процессы падают сами по себе, не руша друг друга, креш потока часто означает креш приложения.
                                        2. Процессы могут жить в уютных песочницах, не пересекаясь друг с другом и с другими процессами вообще ни в чём.
                                        3. Процессы могут следить друг за другом, перезапускать упавшие.
                                        4. Процессы можно контролировать менеджером задач, на счёт потоков можно только узнать их количество.
                                        5. В процесс можно подгрузить чужую дллку-плагин, не боясь, что она упадёт или сделает что-то плохое (по вышеуказанным причинам — песочницы, взаимный контроль).

                                        Я вообще тоже не вижу причин внедрения мультипроцессности для производительности. Но вот для модульности, стабильности, удобства контроля, безопасности — это да.
                                          +1
                                          1) Согласен, но не так часто это происходит.
                                          2) Пожирание памяти. Плюс они хотят использовать общие кеши, так что концепция полного разделения песочниц уже не работает.
                                          3) Этим занимается мастер процесс и это входит в первый пункт (т.к. достаточно очевидно).
                                          4) Убить отдельный поток можно (правда, не стандартным таск менеджером, но обычному юзеру подобное и не снилось). Полагаю речь идёт о сравнительно безопасном убийстве вкладки.
                                          5) Таким образом, если у меня будет 20 вкладок с флешем, то подгрузится он 20 раз? Прощай память.
                                          В целом фишки любопытные, но кроме моих доводов против привели ещё доводы ниже. И так ли востребованы эти фичи?
                                        +1
                                        Странно, коммент обкусило… итак, его окончание:
                                        При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
                                          +1
                                          Facepalm, хабр. Он скушал всё, что шло после " < ", т.к. оно было вплотную к скобке
                                          При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий < 0.05% процессорного времени каждый. И без Хрома получается ~13к смен контекста.

                                          Поэтому я против переделки текущей архитектуры даже при её недостатках, пока не появятся более серьёзные причины, чем те, что обозначены в посте.
                                          +6
                                          А я наоборот, люблю FF за то, что он не забивает мне Task Manager кучей своих процессов.
                                            +2
                                            А зачем вы смотрите в таск-менеджер?
                                              +2
                                              У меня на 2м мониторе виджетами на рабочем столе выведены процессы (по памяти/процессору), загрузка процессора/памяти/сети. Мне очень нравится :)
                                            +2
                                            Это, наверное, единственное, почему я еще не перешел на FF.
                                            Когда разрабатываешь фронтенд и происходит, например, зацикливание, то очень неудобно перезагружать FF целиком.
                                              +5
                                              Вроде как когда-то уже был подобный коммент, где-то год назад. Тогда проверили, музилка предлагает оборвать бесконечный цикл секунд через 15-20 после того, как он все зафризит. Это, конечно, неудобно, надо достаточно долго ждать, но все же не все так страшно.
                                                +1
                                                Да, но когда проект надо сдавать (а нервы уже сдают), то 20 секунд превращается в ад ;)
                                                  +1
                                                  Я не говорю, что это выход. И ни в коем случае не говорю, что это плюс. имеется ввиду, что не все так ужасно ии критично, как кажется на первый взгляд.
                                              +1
                                              Пощупал. Плавности в анимации вкладок действительно добавилось довольно заметно, но начал ощутимо подлагивать скроллинг в текущей вкладке во время загрузки страницы в других. В любом случае, очень рад, что этот проект не забросили.
                                                +1
                                                «Файерфокс» остаётся самым стабильным браузером в мире.

                                                Firefox 25.0.1, 3.12.2-1-ARCH, x86_64. Вот это (можно открывать, не убъет..) до сих пор убивает огнелиса и всю систему, перезагрузится можно только посредством магии SysRq. Прекрасно понимаю что это прекрасно лечится средствами ОС… но мне кажется что это проблема именно firefox'a. У chromium'a например просто отмирает вкладка…
                                                  +4
                                                  Запустил. Firefox 25.0.1, OS X 10.8.5, x86_64, отрисовало прогресс-бар где-то на четверть, после трехсекундной паузы или типа того Firefox предложил завершить выполнение скрипта. Я согласился, после чего закрыл вкладку. Пишу вам. Все работает, систему перегружать не пришлось. Может, это все-таки проблема не совсем Firefox-а? :)
                                                    +1
                                                    Погуглил немного: про это уже тут писали; страдают не все, в том числе повезло пользователям OS X; был багрепорт по этому поводу, но разработчики считают что фитча, так и должно быть:
                                                    Sounds like a straightforward resource consumption issue — especially with a 64-bit build, we can keep allocating lots and lots of memory. Eventually, your OS will start complaining or having issues, but I don't think there's anything we can (or should) do.
                                                      +3
                                                      Рискну выглядеть ололо-фанбоем, но по моему скромному личному мнению, проблема действительно не относится к проблеме Firefox как таковой. Если какая-то программа потребляет слишком много системных ресурсов и мешает остальным, то решение этой проблемы — головная боль именно операционной системы и никого другого.

                                                      Правильным поведением со стороны ОС было бы сохранение отзывчивости всех остальных программ на прежнем уровне и «зависание» браузера, пока он не закончит с выделением всех canvas-ов. А как избежать зависания самого браузера, должен решать уже сам браузер :) Как вариант — переложить задачу на операционную систему, создав отдельные процессы. Как другой вариант, выдавать квоты на потребление ресурсов разным вкладкам и использовать асинхронность/сопроцедуры вместо многопоточности.
                                                        +1
                                                        Отчасти вы правы. Можно ограничить процесс квотами по памяти, с системой все будит хорошо — пострадает только Firefox, но мне лично кажется это не нормально когда интерпретатор считает: скрипту надо 54Gb памяти… дадим или умрем! Лично как по мне, так луше прибивать скрипт если он захотел например больше 1Gb. Только в настройках ФФ я нигде такого не нашел, может просто плохо искал?
                                                          +2
                                                          Нет-нет, вы говорите о более радикальном реагировании на превышение квоты. Я же изначально думал о троттлинге — в случае превышения локальной квоты вводить задержки в функции выделения памяти путем формирования очереди этих вызовов и ожидания освобождения памяти от менее ограниченных задач. Т.о. тот, кто хочет слишком многого, все равно будет работать, но при этом не будет мешать остальным, которые памятью пользуются более разумно.

                                                          При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)
                                                            +1
                                                            Упс… начинаю понимать. Формально вы правы: ОС должна справедливо разделять ресурсы между процессами а процессы — адекватно реагировать на выделение/отказ в выделении. Судя по вашему первому комментарию, OS X умеет сказать процессу: «баста, памяти ты больше не получишь» а Firefox, реагирует на это тем, что прибивает вкладку решившую кушать много памяти. В моем случае тоже все правильно: Firefox'у дают память — он ее использует, и вполне возможно готов отреагировать на сообщение об исчерпании памяти. Но Linux отдает все что у него есть, и геройски погибает. Я пробовал решать эту проблему только через cgroups, возможно существуют более мягкие решения.

                                                            Занимательно, что по поводу этой же ошибки говорят в багзиле ядра (я думаю с точки зрения ОС нет особой разницы между хромом и ФФ):
                                                            This appears to be a google chrome bug in that it tries to allocate most of your memory — you might want to set vm overcommit to disallow heavy overcommit then chrome would I think be killed

                                                            т.е. сравнивая с ответом на багрекере ФФ, понимаем что разработчики ядра и разработчики приложений так и не определились кто должен следить за потреблением ресурсов?

                                                            Большое спасибо за ваши комментарии. Страница-убийца это забавно, но распределение ресурсов и особенно поведение ОС в момент их исчерпания это уже интересно.
                                                  +1
                                                  Firebug теперь не видит содержимое вкладки. Версия FB 1.12.5.
                                                    +2
                                                    На то оно и nightly…
                                                      +1
                                                      Я думаю, что проблема не в найтли, а в том, что теперь содержимое вкладки изолируется от всего остального, в том числе и плагинов. Придётся либо создавать виртуальную копию каждого плагина для каждой отдельной вкладки, либо копию содержимого вкладки под плагин. Хотя это всего лишь догадки, т.к. я не знаком с архитектурой FF.
                                                      +5
                                                      В расширениях для перехода на многопроцессорную архитектуру придется внести очень много изменений.
                                                      Собственно, расширения основной тормоз перехода.
                                                      –4
                                                      Всегда был большим поклонником Firefox и пользовался им до последнего месяца. Настолько сильно тормозить начал. Ни переустановка, ни удаление всех дополнений не помогли. Очень долго запускался, зависал во время работы. Весь нэт перелазил, но не нашел решения проблемы. Пришлось полностью перейти на хром. Немного не привычно, но в общем тоже нормально :) Очень надеюсь что теперь получше станет.
                                                        +1
                                                        мне это менее интересно, чем перевод браузера на 64 бита. Уже скоро новые версии Винды перестанут выпускаться в 32-битной сборке, а ФФ никак не движется в этом направлении (я имею в виду отсутствие стабильных сборок, альтернативная 64-битная и у меня есть).
                                                          +3
                                                          А зачем вам нужна 64 версия браузера?
                                                            +1
                                                            Очевидно же, чтобы было за что бить по наглой рыжей морде :)
                                                              0
                                                              очевидно же, что более полное использование возможностей современной архитектуры значительно улучшает работу браузера, ускоряет разработку и производительность приложения, а также даёт возможность задействовать некоторые новые возможности, в т.ч. новые механизмы безопасности.

                                                          Only users with full accounts can post comments. Log in, please.