Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
>в этом им помогали Том Шустер
Мне кажется, над Fx уже давно стоило поработать человеку с такой фамилией.
Мне кажется, над Fx уже давно стоило поработать человеку с такой фамилией.
позволит усложнить поиск уязвимостей в браузере
Мне одному кажется, что лучше его облегчить с целью их закрытия?
Подчеркивание есть, а дополнительных процессов не вижу, Linux.
Посмотрим, когда заработает.
Посмотрим, когда заработает.
Считаю необходимым процитировать оригинал:
Собрала операционка все браузеры и строго говорит: Предупреждаю! Любого, кто будет чрезмерно жрать память, сразу буду бить по наглой рыжей морде!
С появлением хрома, эта шутка звучит странно :)
К сожалению это так. Chrome это единственный браузер выжирающий ВСЮ память на компьютере по своим соображениям. Сейчас я хоть на FF спасаюсь, ибо он даже гипотетически не может отъесть больше 2 ГБ, а на практике не отъедает даже более 1, при этом видно, что он убирает неиспользуемые страницы из памяти (видимо на диск скидывает), если и тут введут этот ад с мультипроцессностью, я уже и не знаю, что буду делать :( Иногда, при написании статей, для Chrome не хватает 8 ГБ установленной на компе памяти, и это, ИМХО, фейл, а тот же набор вкладок в FF отжирает около 1 ГБ, и при этом ничего не тормозит, а с Chrome cистема уже колом встаёт :(
Давно пора, аж стыдно за Firefox было последние пару лет
С чего бы?
— Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
— Плагины и так давно запускаются в отдельных процессах.
— Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
— Тормоза тоже убрали в рамках проекта «Snappy»
Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
— Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
— Плагины и так давно запускаются в отдельных процессах.
— Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
— Тормоза тоже убрали в рамках проекта «Snappy»
Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
Иногда Firefox зависает на какой нибудь странице и всё. Ничего нельзя сделать кроме как ждать или выгрузить приложение целиком. Возможность принудительно закрыть только одну вкладку была бы отличным решением.
Безопасность процессов-песочниц — не мифическая. В Хроме даже инжектнув свой код в процесс вкладки ты фиг что с ним сделаешь — ни к диску, ни к другим процессам, ни к сети доступа нет. Сидишь в аквариуме и глазками только моргаешь. Процесс лисы имеет все привилегии, безопасности на уровне ОС в нём нет никакой.
Вопрос в том, что заинжектить код в процесс браузера практически невозможно. Для этого есть две возможности: JS и плагины. Плагины и так в отдельном процессе-песочнице уже много лет. А с JS-ом все очень сложно. Базовая идея: подобрать такой код на JavaScript, чтобы при JIT-компиляции результирующий машинный код делал то, что хочется атакующему. Задача эта сложная, и живых примеров подобных атак даже в «лабораторных» условиях еще не создано.
Насчёт памяти, сравнивая с Оперой, не вижу результатов этих усилий.
Первый вопрос, который возникает у большинства, связан с потреблением оперативной памяти. Пользователи убеждены, что больше процессов значит больше занятой памяти.
Я всеми руками за нововведение – главное чтобы потом не стало как в хроме, 10 подпроцессов при 50-ти вкладках и «он уже лёг ногами по направлению взрыва и накрылся простынёй»
А я вот на FF уже только потому, что Chrome, как бы у него там с защитой вкладок было лучше/хуже, тупо не умеет переключать табы по Ctrl+Tab.
Это я к тому, что соревнования браузеров ведутся уже давно, но, сделай хромовцы Ctrl+Tab, это был бы аргумент посильнее всяких там «многих процессов» :)
Это я к тому, что соревнования браузеров ведутся уже давно, но, сделай хромовцы Ctrl+Tab, это был бы аргумент посильнее всяких там «многих процессов» :)
Спасибо за подсказку, работает (Chrome 31.0.1650.57), а я раньше использовал только ctrl-1 2..8 и 9. :)
Это что-то конкретно у вас с ним не то. У меня переключение работает как в Убунте, так и на Маке.
Хм… Надо было написать подробнее:
я предпочитаю, чтобы, если у меня открыты 20 вкладок, но я работаю с двумя (переключаюсь попеременно между), то каждое нажатие Ctrl+Tab переносило бы меня в предыдущую вкладку. Т.е. нажал Ctrl+Tab, отпустил, нажал Ctrl+Tab — вижу при этом только две последние.
А Хром при любом нажатии Ctrl+Tab дальше по кругу отправляет, т.е. все 20 вкладок по очереди.
В Firefox для таких целей можно приделать плагин, а вот Хром комбинацию Ctrl+Tab не дает ни на что повесить — посему народ извращается, делая Ctrl+Q и прочие комбинации, которые близко к Ctrl+Tab. Близко — но не Ctrl+Tab, сами понимаете.
я предпочитаю, чтобы, если у меня открыты 20 вкладок, но я работаю с двумя (переключаюсь попеременно между), то каждое нажатие Ctrl+Tab переносило бы меня в предыдущую вкладку. Т.е. нажал Ctrl+Tab, отпустил, нажал Ctrl+Tab — вижу при этом только две последние.
А Хром при любом нажатии Ctrl+Tab дальше по кругу отправляет, т.е. все 20 вкладок по очереди.
В Firefox для таких целей можно приделать плагин, а вот Хром комбинацию Ctrl+Tab не дает ни на что повесить — посему народ извращается, делая Ctrl+Q и прочие комбинации, которые близко к Ctrl+Tab. Близко — но не Ctrl+Tab, сами понимаете.
Так понял. Мне как-то удобнее гонять по кругу, а назад через Ctrl+Shift+Tab.
странно, у меня FF последней версии, но Ctrl+Tab работает по кругу
Я лично использую en.design-noir.de/mozilla/ctrl-tab/, вроде то же можно включить в настройках, но я не искал долго.
В Хроме же даже плагин не помогает, нельзя там на эту комбинацию клавиш забиндиться…
В Хроме же даже плагин не помогает, нельзя там на эту комбинацию клавиш забиндиться…
Большое спасибо! К такому удобному переходу между используемыми вкладками привык в продуктах JetBrains. Надо будет обязательно попробовать плагин.
Можно выставить browser.ctrlTab.previews в true, при переключении табов будут рисоваться превьюшки, и побочным эффектом будет как раз порядок переключения.
Tab Mix Plus позволяет настроить массу всякого, связанного с вкладками, в том числе и это.
Раньше в chrome удобнее было Ctrl + -> и Ctrl + < — , а потом сделали как везде по Ctrl + Tab и Ctrl + Shift + Tab :(, если первое ещё юзабельно, то второе сочетание уже не так удобно, да и возможности быстро щёлкнуть вперёд — назад тоже не стало.
Мне интересно с низкоуровневой точки зрения. Чем процессы лучше потоков? Лучше управляются ОС? Или быстродействие повысится за счёт разнесения вкладок на разные процессы? А почему не потоки? Вот сейчас у меня в запущенной в винде последней лисе 58 потоков, так что при желании она загрузит все 4 ядра. Значит, мы не теряем производительность за из-за того, что всё работает на одном ядре.
У меня сейчас в лисе открыто около 150 вкладок (оставим в стороне вопросы как, зачем и почему), большинство из них не подгружены и висят поскольку постольку. При этом лиса отъедает 0.45-10% процессора. А что будет, если на каждую хотя бы подгруженную (около 15 из 150 сейчас) вкладку будет по процессу? А если все 150? Ладно, что та же нагрузка будет распределена по процессам, но мы получаем оверхед на переключения контекста.
Открываю Comodo Dragon (вариант хрома), 5 вкладок, 7 процессов + мастер-процесс, итого 8. Они в сумме генерируют около тысячи дополнительных смен контекста в секунду! При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
У меня сейчас в лисе открыто около 150 вкладок (оставим в стороне вопросы как, зачем и почему), большинство из них не подгружены и висят поскольку постольку. При этом лиса отъедает 0.45-10% процессора. А что будет, если на каждую хотя бы подгруженную (около 15 из 150 сейчас) вкладку будет по процессу? А если все 150? Ладно, что та же нагрузка будет распределена по процессам, но мы получаем оверхед на переключения контекста.
Открываю Comodo Dragon (вариант хрома), 5 вкладок, 7 процессов + мастер-процесс, итого 8. Они в сумме генерируют около тысячи дополнительных смен контекста в секунду! При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
1. Процессы падают сами по себе, не руша друг друга, креш потока часто означает креш приложения.
2. Процессы могут жить в уютных песочницах, не пересекаясь друг с другом и с другими процессами вообще ни в чём.
3. Процессы могут следить друг за другом, перезапускать упавшие.
4. Процессы можно контролировать менеджером задач, на счёт потоков можно только узнать их количество.
5. В процесс можно подгрузить чужую дллку-плагин, не боясь, что она упадёт или сделает что-то плохое (по вышеуказанным причинам — песочницы, взаимный контроль).
Я вообще тоже не вижу причин внедрения мультипроцессности для производительности. Но вот для модульности, стабильности, удобства контроля, безопасности — это да.
2. Процессы могут жить в уютных песочницах, не пересекаясь друг с другом и с другими процессами вообще ни в чём.
3. Процессы могут следить друг за другом, перезапускать упавшие.
4. Процессы можно контролировать менеджером задач, на счёт потоков можно только узнать их количество.
5. В процесс можно подгрузить чужую дллку-плагин, не боясь, что она упадёт или сделает что-то плохое (по вышеуказанным причинам — песочницы, взаимный контроль).
Я вообще тоже не вижу причин внедрения мультипроцессности для производительности. Но вот для модульности, стабильности, удобства контроля, безопасности — это да.
1) Согласен, но не так часто это происходит.
2) Пожирание памяти. Плюс они хотят использовать общие кеши, так что концепция полного разделения песочниц уже не работает.
3) Этим занимается мастер процесс и это входит в первый пункт (т.к. достаточно очевидно).
4) Убить отдельный поток можно (правда, не стандартным таск менеджером, но обычному юзеру подобное и не снилось). Полагаю речь идёт о сравнительно безопасном убийстве вкладки.
5) Таким образом, если у меня будет 20 вкладок с флешем, то подгрузится он 20 раз? Прощай память.
В целом фишки любопытные, но кроме моих доводов против привели ещё доводы ниже. И так ли востребованы эти фичи?
2) Пожирание памяти. Плюс они хотят использовать общие кеши, так что концепция полного разделения песочниц уже не работает.
3) Этим занимается мастер процесс и это входит в первый пункт (т.к. достаточно очевидно).
4) Убить отдельный поток можно (правда, не стандартным таск менеджером, но обычному юзеру подобное и не снилось). Полагаю речь идёт о сравнительно безопасном убийстве вкладки.
5) Таким образом, если у меня будет 20 вкладок с флешем, то подгрузится он 20 раз? Прощай память.
В целом фишки любопытные, но кроме моих доводов против привели ещё доводы ниже. И так ли востребованы эти фичи?
Странно, коммент обкусило… итак, его окончание:
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
Facepalm, хабр. Он скушал всё, что шло после " < ", т.к. оно было вплотную к скобке
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий < 0.05% процессорного времени каждый. И без Хрома получается ~13к смен контекста.
Поэтому я против переделки текущей архитектуры даже при её недостатках, пока не появятся более серьёзные причины, чем те, что обозначены в посте.
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий < 0.05% процессорного времени каждый. И без Хрома получается ~13к смен контекста.
Поэтому я против переделки текущей архитектуры даже при её недостатках, пока не появятся более серьёзные причины, чем те, что обозначены в посте.
А я наоборот, люблю FF за то, что он не забивает мне Task Manager кучей своих процессов.
Это, наверное, единственное, почему я еще не перешел на FF.
Когда разрабатываешь фронтенд и происходит, например, зацикливание, то очень неудобно перезагружать FF целиком.
Когда разрабатываешь фронтенд и происходит, например, зацикливание, то очень неудобно перезагружать FF целиком.
Пощупал. Плавности в анимации вкладок действительно добавилось довольно заметно, но начал ощутимо подлагивать скроллинг в текущей вкладке во время загрузки страницы в других. В любом случае, очень рад, что этот проект не забросили.
«Файерфокс» остаётся самым стабильным браузером в мире.
Firefox 25.0.1, 3.12.2-1-ARCH, x86_64. Вот это (можно открывать, не убъет..) до сих пор убивает огнелиса и всю систему, перезагрузится можно только посредством магии SysRq. Прекрасно понимаю что это прекрасно лечится средствами ОС… но мне кажется что это проблема именно firefox'a. У chromium'a например просто отмирает вкладка…
Запустил. Firefox 25.0.1, OS X 10.8.5, x86_64, отрисовало прогресс-бар где-то на четверть, после трехсекундной паузы или типа того Firefox предложил завершить выполнение скрипта. Я согласился, после чего закрыл вкладку. Пишу вам. Все работает, систему перегружать не пришлось. Может, это все-таки проблема не совсем Firefox-а? :)
Погуглил немного: про это уже тут писали; страдают не все, в том числе повезло пользователям 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.
Рискну выглядеть ололо-фанбоем, но по моему скромному личному мнению, проблема действительно не относится к проблеме Firefox как таковой. Если какая-то программа потребляет слишком много системных ресурсов и мешает остальным, то решение этой проблемы — головная боль именно операционной системы и никого другого.
Правильным поведением со стороны ОС было бы сохранение отзывчивости всех остальных программ на прежнем уровне и «зависание» браузера, пока он не закончит с выделением всех canvas-ов. А как избежать зависания самого браузера, должен решать уже сам браузер :) Как вариант — переложить задачу на операционную систему, создав отдельные процессы. Как другой вариант, выдавать квоты на потребление ресурсов разным вкладкам и использовать асинхронность/сопроцедуры вместо многопоточности.
Правильным поведением со стороны ОС было бы сохранение отзывчивости всех остальных программ на прежнем уровне и «зависание» браузера, пока он не закончит с выделением всех canvas-ов. А как избежать зависания самого браузера, должен решать уже сам браузер :) Как вариант — переложить задачу на операционную систему, создав отдельные процессы. Как другой вариант, выдавать квоты на потребление ресурсов разным вкладкам и использовать асинхронность/сопроцедуры вместо многопоточности.
Отчасти вы правы. Можно ограничить процесс квотами по памяти, с системой все будит хорошо — пострадает только Firefox, но мне лично кажется это не нормально когда интерпретатор считает: скрипту надо 54Gb памяти… дадим или умрем! Лично как по мне, так луше прибивать скрипт если он захотел например больше 1Gb. Только в настройках ФФ я нигде такого не нашел, может просто плохо искал?
Нет-нет, вы говорите о более радикальном реагировании на превышение квоты. Я же изначально думал о троттлинге — в случае превышения локальной квоты вводить задержки в функции выделения памяти путем формирования очереди этих вызовов и ожидания освобождения памяти от менее ограниченных задач. Т.о. тот, кто хочет слишком многого, все равно будет работать, но при этом не будет мешать остальным, которые памятью пользуются более разумно.
При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)
При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)
Упс… начинаю понимать. Формально вы правы: ОС должна справедливо разделять ресурсы между процессами а процессы — адекватно реагировать на выделение/отказ в выделении. Судя по вашему первому комментарию, 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
т.е. сравнивая с ответом на багрекере ФФ, понимаем что разработчики ядра и разработчики приложений так и не определились кто должен следить за потреблением ресурсов?
Большое спасибо за ваши комментарии. Страница-убийца это забавно, но распределение ресурсов и особенно поведение ОС в момент их исчерпания это уже интересно.
Firebug теперь не видит содержимое вкладки. Версия FB 1.12.5.
На то оно и nightly…
Я думаю, что проблема не в найтли, а в том, что теперь содержимое вкладки изолируется от всего остального, в том числе и плагинов. Придётся либо создавать виртуальную копию каждого плагина для каждой отдельной вкладки, либо копию содержимого вкладки под плагин. Хотя это всего лишь догадки, т.к. я не знаком с архитектурой FF.
В расширениях для перехода на многопроцессорную архитектуру придется внести очень много изменений.
Собственно, расширения основной тормоз перехода.
Собственно, расширения основной тормоз перехода.
Всегда был большим поклонником Firefox и пользовался им до последнего месяца. Настолько сильно тормозить начал. Ни переустановка, ни удаление всех дополнений не помогли. Очень долго запускался, зависал во время работы. Весь нэт перелазил, но не нашел решения проблемы. Пришлось полностью перейти на хром. Немного не привычно, но в общем тоже нормально :) Очень надеюсь что теперь получше станет.
мне это менее интересно, чем перевод браузера на 64 бита. Уже скоро новые версии Винды перестанут выпускаться в 32-битной сборке, а ФФ никак не движется в этом направлении (я имею в виду отсутствие стабильных сборок, альтернативная 64-битная и у меня есть).
А зачем вам нужна 64 версия браузера?
Очевидно же, чтобы было за что бить по наглой рыжей морде :)
очевидно же, что более полное использование возможностей современной архитектуры значительно улучшает работу браузера, ускоряет разработку и производительность приложения, а также даёт возможность задействовать некоторые новые возможности, в т.ч. новые механизмы безопасности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультипроцессовый Firefox