Pull to refresh

Comments 31

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

Тест синтетический и провокационный. Это все равно что положить перед ребенком конфету и сказать «не ешь!», и каждые пол секунды добавлять еще конфетку.

Воспитанный ребенок конфетки кушать не будет, сколько бы их не было, а непослушный почти сразу за них примется. Пример, может и далековат от реалий, но иллюстрирует принцип, которым руководствуется хром и его собратья по несчастью.

Кстати, в защиту хрома хотелось бы сказать, что отвалилась только вкладка с неугодным скриптом.

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

Вообще-то вы ошибаетесь и новых конфет там не кладут, а заменяют одну на другую. Т.е. в один и тот же элемент грузят новые картинки, при этом ссылок на старые не остается и их стоило бы освобождать.
Увы, но в Хромиуме (и, видимо, в Хроме) не каждая вкладка отдельный процесс — вот у меня сейчас один процесс на эту вкладку и ещё 11.
В Хроме каждая вкладка — отдельный процесс, только что посмотрел в Таск Менеджере, версия 11.0.696.60 unknown
В хромиуме так, насколько я понял, только пока вкладок <6. Когда их число >30, то процессов с --type=renderer всё равно 5. Смотрел через htop.

А откуда цифра 30? Я вот нашел доку по их процессной модели

www.chromium.org/developers/design-documents/process-models

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

Но я в любом случае был неправ, каюсь.
Просто прикинул число открытых у себя вкладок :)

Но вот с per-site как-то тоже не вяжется — прямо сейчас две группы вкладок с хабром разбиты на два процесса, в каждом есть и другие сайты (правда все они открыты или с линков на хабре, или с поиска в адресной строке «поверх» habrahabr.ru/… с последующим alt+enter).

Хотя, может быть, настройки у меня не дефолтные, ставлю с пакетов
К сайту, демонстрирующиму уязвимость пришел хабраэффект.
Если б оно стояло не на Гугл Апп, а на вирт хостинге, то хабраэффект и вирт хостинг положил бы
Даже гугл не выдержал хабраэффекта :D
Уточнение: хабраэффекта не выдержали финансы автора теста:)
Самая главная утечка — фаербаг, вот я бы счастлив был — не перегружать постоянно лису
Просто одни больше, другие меньше.
Читаю заголовок и мозг уже сам подставляет окончание (:
«Почти все современные браузеры страдают от утечек памяти, alizar»
Работал я как-то с QWebView (из QT), на платформе Symbian. Если в него грузить картинки, то у телефона память кончается на 5-7 картинке.
Так что можно утверждать, что все браузеры страдают от утечек памяти.
Но тут нечему удивляться, ведь писали эти вещи люди, они имеют право на ошибки
UFO just landed and posted this here
В FF 3.6 этого бага вроде нет.
Это точно. Сафари на маке сжирает гиг оперативы враз!
Без паники! Проблема решается установкой 64x-bit ОС + 6 гигов оперативы. Проверил на себе.
И можно месяц браузер не рестартовать?
Месяц не знаю — но неделю в легкую.

У меня постоянно запущен хром (10+ закладок), firefox, opera, photoshop.
Иногда IE и мелкий софт. Комп не выключаю.

Занято памяти 3-4 гига. Все летает, ниче не падает, не тормозит. Жизнь прекрасна!
Попробовать что ли своп увеличить до 6 гигов :)
если винч шустрый — пробуй. если нет -то лагать будет аццки
Ну, я также починил проблему на маке — купив 8Gb (благо
А зачем 64бит? PAE чем не устраивает?
вот отстой :(
у меня 64 ОС, но 4гб максимум что можно впихнуть
Ха, я еще в 2004 году жаловался на linux.org.ru на то, что у меня Firebird/Firefox ест гигабайт памяти (а у меня тогда всего гигабайт было), даже если не открыта ни одна вкладка. Меня обсмеяли и сказали, что я гоню.
Sign up to leave a comment.

Articles