Firefox 3: работа по устранению утечек памяти и уменьшения её использования

> Firefox 3 будет использовать меньше ОЗУ, чем Firefox 2, в особенности, если вы бродите по Интернету в течение долгого времени

А между тем вернёмся к действительности - хвалёный Iceweasel иногда и пятнадцати минут не держится - дохнет, хотя из чувства солидарности продолжаю его использовать в Debian, но на Rythmbox терпения не хватило - он у меня таки самособранный. Официальный Firefox никогда так себя не вёл в Fedora, как Iceweasel в Debian скажу я вам. И это не комплимент Iceweasel.

>А какие нибудь приложения кроме фаерфокса страдают от этого? У меня вот емакс часто долго висит, вроде память не сжирает, гном тот же.

даже на данной странице- 12 картинок и 3 javascriptа. А ведь это не самая нагруженная страница весьма минималистического LORа.

IMXO, если попробовать в емакс открывать/закрывать десятки файлов разного размера раз в минуту по несколько часов несколько дней- думаю произойдёт то, что незнакомые с терминологией журналисты называют "утечками памяти".

> К сожалению, о старой ошибке, связанной с некорректным высвобождением памяти библиотекой glibс, не упоминается. На данный момент существует только неофициальное решение.

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

В третьий решение есть:

http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools

заодно оно позволяет профилировать аллокации и находить утечки.

Нет они вот уже который год толдонят "у нас всё хорошо, это аллокатор кривой".

Для khtml и opera значит он годится, а для мазиллы кривой! :-D

Opera течёт, см. первую страницу.

> Мозилла памяьть обратно отдаёт.

типа закачки обратно :-)

История мутная. Что _должно_ оставаться в памяти после выгрузки web страницы? Заголовки в history и Location? Куки?

Неужели проверить им трудно? А Iceweasel только тем от фирменной сборки отличается, что с pango собран...

>http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools
>заодно оно позволяет профилировать аллокации и находить утечки.

проверяли уже- может, правда, не GooglePerformanceTools, а ещё чем-то подобным- но сути не меняет: того, что называется утечками в FireFox нет,( уж по крайней мере видимых невооружённым взглядом- точно).

> хвалёный Iceweasel иногда и пятнадцати минут не держится - дохнет

apt-get update && apt-get upgrade пробовали? может у вас какие либы конфликтуют? у меня лично ниразу никаких проблем с ним не было. Debian sid.

>Opera течёт, см. первую страницу.

Висит сутками и открыты десятки табов. Ни разу не видел, чтобы потребляла больше 200..300Мб оперативки при среднем потреблении около 100..150Мб. Firefox в среднем жрёт 150..250Мб, нередко вылезает до 500..700Мб, а пару раз, оставленный на выходные, отжирал всю оперативку со свопом и едва убивал машину - http://balancer.ru/tech/forum/2007/06/15/topic-50894--Firefox-i-pamyat'.To-li-v -yumor,to-li-v-slyozy....html

Ты вообще понимаешь, чем malloc отличается от ядерного вызова? И зачем он вообще нужен, раз mmap есть.

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

Ну вот, всё свалили на С...

а в чем прикол гонять бравзер сутками с сотнями открытых окон? я всегда если заканчиваю лазить в нете - закрываю бравзер. И никогда никаких проблем с особым потреблением памяти в ФФ не замечаю. Ну 200м, ну 300 бывало, но мне то не особо критично...

> а в чем прикол гонять бравзер сутками с сотнями открытых окон?

"невыключаемый" ноут ? :)

... и неубиваемый браузер...

Используя нестандартоне решение лиса потребляет меньше памяти но все равно со временем все растет и растет. Приходится еше и ораничивать по RAM:

ulimit -m 300000 ; LD_PRELOAD=/opt/malloc.so /usr/local/firefox2/firefox

Я хоть и другой анонимус, но отвечу тебе.

> Ты вообще понимаешь, чем malloc отличается от ядерного вызова?
Тем, что работает быстрее на порядок т.к. не
всегда к ядру обращается. mmap() выделяет куски,
кратные 4К, и по этому если делать несколько
маленьких malloc(), то mmap()/brk() из них будет только
один. Кстати, по-моему, последние glibc() используют
именно mmap(), хотя могу ошибаться.

> И зачем он вообще нужен, раз mmap есть.
Чтобы поддерживать стандарт ANSI-C.

How to help

You don't have to be a C++ programmer to help find leaks in Firefox.

If you're a Firefox user, an easy way to help is to browse with a trunk nightly build wrapped in a script that calls leak-gauge.pl ( http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.pl?raw=1 )
when Firefox exits. If it reports that documents or windows leaked, try to figure out how to reproduce the leak and then file a bug report.

Аналогично, но ФФ для Web-разработки нужен: ни у Оперы, ни у Конкуерора таких плагинов нет (один firebug + InspectThis чего стоят, да и Tidy...).
У меня на Фаерфокс 75 плагинов навешено. Из них примерно половина постоянно активны, а остальные - от случая к случаю. Памяти это все жрет немеряно, а куда деваться то? :(
А если ко всему этому прибавить Eclipse (тоже не пустой - ~70-80 плагинов), Aqua DataStudio, Open Office... То получится, что для нормального процесса разработки сложных коммерческих проектов (про Apache тоже не забываем: иногда некоторые проекты требуют 128Мб на скрипт) выходит, нужно не менее 1,5 Гб мозгов :)

у тебя есть возможность скачать тулзы и отрепортить меморилики в твоих 75 плагинах... Там чел только 20 самых популярных плагинов протестил на мемори лики.

>Пул -- кусок памяти _фиксированного_ размера, выделяемый через mmap
И какова размера он должен быть? А если не хватит?

У меня почти одинаково отжирают память что FF, что Konqueror, что Опера при открытии большого числа табов, иногда конк срывается на процессоре. Одна разница - тормоза по-разному проявляются. Xorg тоже растёт... :( Знать бы в чём дело

512 рамы + гиг свопа.

А зачем нужно менять malloc на mmap, если можно одним вызовом объяснить malloc когда юзать mmap?

You can adjust some parameters for dynamic memory allocation with the
`mallopt' function.  This function is the general SVID/XPG interface,
defined in `malloc.h'.  

 -- Function: int mallopt (int PARAM, int VALUE)
...
    `M_MMAP_THRESHOLD'
          All chunks larger than this value are allocated outside the
          normal heap, using the `mmap' system call.  This way it is
          guaranteed that the memory for these chunks can be returned
          to the system on `free'.  Note that requests smaller than
          this threshold might still be allocated via `mmap'.

Поставил 8-ю альфу трёшки, пару раз за день успел упасть. При этом даже без серфинга, просто был запущен, а я в это время работал с другим приложением. Может так решили бороться с неосвобождением памяти - методом принудительного завершения? :)))
Тем неменее перепробовав многое и подолгу (включая Opera и Konqueror) привык и пользуюсь под Linux и Windows FF2 (как быйдет первая бета, может на третий перейду). А вот под MacOS X предпочитаю на Safari 3 (но на офтопике он у меня не прижился из-за невозможности использовать плагины и откровенной сыроватости) :)

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

Ты имеешь в виду boehm-gc? Ты читал, как он работает? Это жутчайший хак, я бы с ним вообще не связывался... Когда нет поддержки GC на уровне языка и, соответственно, компилятора, приходится вот так извращаться...

>И какова размера он должен быть? А если не хватит?

Ээээ... Ну почесать этот, как его, моск и посчитать... В конце концов, взять с запасом. Афаик, память же _реально_ отдаётся процессу всё равно не при вызове mmap, а уже при обращении, по эксепшену. Так что пусть останутся неиспользуемые куски.

фтопку ) конк наше фсе

> у тебя есть возможность скачать тулзы и отрепортить меморилики в твоих 75 плагинах... Там чел только 20 самых популярных плагинов протестил на мемори лики.

Уже думал об этом, тулзы скачал. Найду время - протещу все. Все-таки, как инструмент веб-разработки он не заменим, хотелось бы, чтобы он стал еще лучше.

> Поставил 8-ю альфу трёшки, пару раз за день успел упасть. При этом > даже без серфинга, просто был запущен, а я в это время работал с > другим приложением. Может так решили бороться с неосвобождением памяти > - методом принудительного завершения? :)))

У меня как раз эти альфы работают чрезвычайно стабильно. Конк рушится гоораздо чаще. Но везде всё портит занимаемая память.

> Нет они вот уже который год толдонят "у нас всё хорошо, это аллокатор кривой".

> Для khtml и opera значит он годится, а для мазиллы кривой! :-D

Не годится, к сожалению. Фрагментация в opera: http://www.linux.org.ru/view-message.jsp?msgid=1984162&page=5#2000724

Желающие могут прогнать такой тест с konqueror.

P.S. konqueror значительно меньше теряет на фрагментацию при использовании http://mr.himki.net/OpenBSD_malloc_Linux.c, чем c glibc.

> Ты вообще понимаешь, чем malloc отличается от ядерного вызова? И зачем он вообще нужен, раз mmap есть.

А затем нужен, чтобы вызывать brk() и/или mmap()/mremap()/munmap(). Марш читать glibc-2.*/malloc/malloc.c

> А зачем нужно менять malloc на mmap, если можно одним вызовом объяснить malloc когда юзать mmap?

Менять malloc на mmap _не нужно_. Нужно, чтобы malloc правильно использовал mmap().

В glibc низкий MMAP_THRESHOLD не поможет. Пусть, например, MMAP_THRESHOLD = 16. malloc(16) тогда приводит к вызову mmap(0,4096,...), следующий malloc(16) приведет опять к вызову mmap(0,4096,...), несмотря на наличие в только что отмапленной странице свободного места. В glibc MMAP_THRESHOLD только для запросов >> 4К.

> Firefox в среднем жрёт 150..250Мб, нередко вылезает до 500..700Мб, а пару раз, оставленный на выходные, отжирал всю оперативку со свопом и едва убивал машину -

Все те же лица. Пора взрослеть? Списочек страниц в студию, на которых нередко вылезает до 500..700Мб?

>Все те же лица.

Всё те же труЪ лоровцы.

>Списочек страниц в студию, на которых нередко вылезает до 500..700Мб?

По ссылке сходи.

>Ээээ... Ну почесать этот, как его, моск и посчитать... В конце концов, взять с запасом. Афаик, память же _реально_ отдаётся процессу всё равно не при вызове mmap, а уже при обращении, по эксепшену. Так что пусть останутся неиспользуемые куски.

Дык а сколько по-твоему будет достачточно? 10Мб, 100Мб или может быть сразу с запасом все 4Гб выдклять?

>>Списочек страниц в студию, на которых нередко вылезает до 500..700Мб?

> По ссылке сходи.

http://users.skynet.be/mgueury/mozilla/no_tidy_lib.html http://users.skynet.be/mgueury/mozilla/no_tidy_lib.html http://www.vim.org/tips/tip.php?tip_id=211 http://mozex.mozdev.org/arguments.html#textarea http://community.i-rs.ru/index.php/topic,1668.0.html http://sourceforge.net/projects/quantum http://balancer.ru/ http://trac.balancer.ru/fortress/

$ ps -eo pid,rss,vsz,size,comm |grep -E "COMMAND|firefox" PID RSS VSZ SZ COMMAND 17187 1108 2008 152 firefox 17195 48500 66760 35128 firefox-bin 17198 48500 66760 35128 firefox-bin 17199 48500 66760 35128 firefox-bin 17203 48500 66760 35128 firefox-bin

Где здесь 500Mb?

Вопрос, на который вам просто необходимо ответить: что выводит top в колонку VIRT?

Форматирование.


>>Списочек страниц в студию, на которых нередко вылезает до 500..700Мб?

> По ссылке сходи.

http://users.skynet.be/mgueury/mozilla/no_tidy_lib.html
http://users.skynet.be/mgueury/mozilla/no_tidy_lib.html
http://www.vim.org/tips/tip.php?tip_id=211
http://mozex.mozdev.org/arguments.html#textarea
http://community.i-rs.ru/index.php/topic,1668.0.html
http://sourceforge.net/projects/quantum
http://balancer.ru/
http://trac.balancer.ru/fortress/

$ ps -eo pid,rss,vsz,size,comm |grep -E "COMMAND|firefox"
PID RSS VSZ SZ COMMAND
17187 1108 2008 152 firefox
17195 48500 66760 35128 firefox-bin
17198 48500 66760 35128 firefox-bin
17199 48500 66760 35128 firefox-bin
17203 48500 66760 35128 firefox-bin

Где здесь 500Mb?

Вопрос, на который вам просто необходимо ответить: что выводит top в колонку VIRT?

>Где здесь 500Mb?

Так, прогресс уже небольшой есть. Теперь Вам ещё нужно научиться читать - и тогда можно будет продолжить диалог.

>что выводит top в колонку VIRT?

Почитайте написанное.

> Почитайте написанное.

Еще раз: что выводит top в колонку VIRT?

Хинт: man top, man ps.

Может хватит демонстрировать безграмотность?

> а в чем прикол гонять браузер сутками с сотнями открытых окон? я всегда если заканчиваю лазить в нете - закрываю бравзер.

А зачем его закрывать, чтобы потом опять открывать? )) Открыл ссылку с интересной серьезной статьей, но времени читать нет - пусть будет открытой до выходных, пока время не появится. Так оно все скапливается. У меня до сотни никогда не доходило. Но 20 бывает.

> У меня до сотни никогда не доходило. Но 20 бывает.

Аналогично. mozilla 1.7.13 распухает за неделю обычного использования (документация, странички без наворотов, иногда youtube.com) до ~100Мб, и остается на этом уровне. Одновременно бывает открыто 20-50 вкладок в нескольких окнах.

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

>Еще раз: что выводит top в колонку VIRT?

Ещё раз - сходи и почитай.

>Может хватит демонстрировать безграмотность?

Может, хватит демонстрировать полное неумение читать?

> Ещё раз - сходи и почитай.

Делаем вид, что не понимаем вопроса?

Еще раз, чтоб совсем понятно было: как подсчитывается число, выводимое программой top в колонку VIRT?

> Еще раз, чтоб совсем понятно было: как подсчитывается число, выводимое программой top в колонку VIRT?

Да какая на хрен разница? Кого этот VIRT вообще волнует, тем более когда системы 64-х битные нынче (вон у меня проги больше двух гигов VIRT жрут - и ничего, кстати одна из них - java ;) )? Проблема в распухании RES.

>Делаем вид, что не понимаем вопроса?

Нет, полное непонимание вопроса с другой стороны.

> Проблема в распухании RES.

У него на картинке RES = 64M.

А в VIRT попадает, в том числе, все mmap-нутое процессом.

См., например, http://balancer.ru/img/forums/0608/OperaFoxMem.png: 272M "съел" weather-applet, 185M clock-applet, 211M gnome-terminal.

Автору сего фото учить матчасть, дабы не позориться в дальнейшем.

>>Делаем вид, что не понимаем вопроса?

> Нет, полное непонимание вопроса с другой стороны.

Анонимус прав, virt -- ничего не значит.

> К сожалению, о старой ошибке, связанной с некорректным высвобождением памяти библиотекой glibс, не упоминается. На данный момент существует только неофициальное решение.

Это не ошибка, уже говорилось здесь.

Кроме OpenBSD-malloc, есть еще hoard: http://www.hoard.org/

При освобождении непрерывного куска размером > SUPERBLOCK_SIZE/2 (по умолчанию SUPERBLOCK_SIZE = 65536, можно снизить до 2*PAGE_SIZE = 8192) он вызывает munmap, и память системе возвращается.

Mozilla с ним иногда падает, но 1) память возвращается 2) субъективно шустрее, чем с openbsd-malloc или default glibc

Описание принципа работы:

E.D.Berger, et. al., Hoard: A Scalable Memory Allocator for Multithreaded Applications, http://www.cs.umass.edu/%7Eemery/pubs/berger-asplos2000.pdf

> apt-get update && apt-get upgrade пробовали? может у вас какие либы конфликтуют?

Это всё понятно - обновляться полезно, но дело наверное в специфике архитектуры - amd64(imho правильнее её было обозвать x86_64 как в федоре и других) под CoreDuo2.

> Debian sid

аналогично :)

>Анонимус прав, virt -- ничего не значит.

Видишь ли, даже когда Фокс свёрнут и RES у него 64М, но при этом VIRT хотя бы 700Мб - машина уже еле шевелится. Особенно на nForce3 чипсете, где чудовищно кривой PATA. При попытке развернуть его - система вообще практически ложится. Даже не смотря на CFQ :)

...

В общем, подобные рассуждения о "невлиянии" VIRT может разве что сугубый теоретик двигать. Перезагружающий свой комп дважды в день, и потом не нарывавшийся хотя бы на 500-меговый жор Фокса. И, как уже писалось, совершенно не умеющий читать. Ибо писалось.