LINUX.ORG.RU
ФорумTalks

Firefox: потребление памяти & malloc


0

0

Здесь периодически пишется про потребление и неотдачу памяти базирующимися на mozilla браузерами (mozilla, seamonkey, firefox, netscape).

Характерное поведение mozilla такое:

1) размер VM на старте ~20-25 M

2) размер VM при ~30 открытых табах ~80M

3) после закрытия табов VM заметно не уменьшается, остается на уровне тех ~80M.

В итоге, VM браузера в среднем по времени сеанса растет, VM не возвращается ядру при закрытии табов и/или окон, что приводит к торможению всей системы.

При отключенных кэшах потребление VM заметно не меняется.

К "программным" утечкам памяти (забытые free()/delete) это не имеет отношения: https://bugzilla.mozilla.org/show_bug.cgi?id=324081#c17

В А Ж Н О: Это характерно для mozilla/firefox/seamonkey/netscape под __Linux__.

Например, под OpenBSD 3.8 firefox _возвращает_ память ядру при закрытии табов/страниц в ожидаемом количестве, т.к. в OpenBSD malloc() сделан только на mmap(), и sbrк() вообще там не используется. (см. http://www.linux.org.ru/profile/_white/view-message.jsp?msgid=1369016#1375917)

Это показывает, что в прожорливости mozilla под GNU/Linux виновата реализация malloc/free, использующая sbrk().

---------------------------------------------------

Призыв к трудящимся, использующим mozilla-based браузеры:

1) оставьте свое мнение о потреблении VM в соответствующем месте в bugzilla.mozilla.org:

https://bugzilla.mozilla.org/show_bug.cgi?id=324081

2) если кто-то уже пытался перенести malloc() et al. из OpenBSD под linux, дайте знать, это решает проблему.

Всех с 1 Мая!

anonymous
Ответ на: комментарий от skyfisher

Убедительная просьба высказываться по существу.

PS: opera, konqueror, etc, etc, ведут себя под linux в смысле VM точно также.

anonymous
()
Ответ на: комментарий от anonymous

А может накатать пример, который это явно может показать ?

На подобии

while (...) { mem_ary[i] = malloc(random_chunk_size); i++; }; // check memory usage // free random chunks and check mem. usage ...

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

halflife ★★
()
Ответ на: комментарий от Selecter

>Ещё учтите, что ps неправильную инфу показывает

malloc_stats() зато правильную, см. ссылку выше на bugzilla.

anonymous
()

Что-то я юмора не понял. На кой авторам firefox дался bugreport о реализации malloc и free в libc под Linux? Авторам libc это надо писать.

devinull ★★
()
Ответ на: комментарий от devinull

> На кой авторам firefox дался bugreport о реализации malloc и free в libc под Linux?

malloc в glibc (aka ptmalloc) подходит для большинства приложений.

Менять его на что-л. другое как минимум опрометчиво, посылать это как bug авторам glibc -- глупо.

Проще прикрутить специальный malloc к браузеру, который действительно имеет проблему с динамич. выделением/освобождением памяти.

anonymous
()
Ответ на: комментарий от anonymous

А заодно и авторам еще пары сотен приложений с аналогичной проблемой? Что-то надо в libc менять, все-таки, если уж правда так все плохо.

devinull ★★
()
Ответ на: комментарий от devinull

> А заодно и авторам еще пары сотен приложений с аналогичной проблемой?

Какие приложения под linux имеют аналогичную проблему ?

anonymous
()
Ответ на: комментарий от anonymous

Ну не один же firefox этим страдает. Уверен, что если у него проблемы именно там, то значит и еще у кучи приложений тоже.

devinull ★★
()
Ответ на: комментарий от devinull

> Уверен, что если у него проблемы именно там, то значит и еще у кучи приложений тоже.

Для bugreport по glibc одной вашей уверенности мало :))

anonymous
()
Ответ на: комментарий от devinull

> Посмотрим, что авторы firefox ответят. ;)

По памяти цитата кого-то из moz. developers, ~2005 г.:

" ... Never before we approached so close to a complete replacement of the RTL memory management ..."

btw, альтернативные аллокаторы уже включались в CVS mozilla. dlmalloc до сих пор есть в дереве, собирать xpcom с ним можно по желанию.

anonymous
()
Ответ на: комментарий от anonymous

Какие приложения под linux имеют аналогичную проблему ? Например у меня опера ведет себя примерно также, правда речь про 9-beta1 ибо 8.х пробовал раньше не нравилось совсем, решил попробовать 9ку понравилось больше но недостаточно чтоб слезть с ФФ.

anonymous
()
Ответ на: комментарий от anonymous

> Например у меня опера ведет себя примерно также

+konqueror, +galeon, +epiphany, +netscape, +все долгоиграющие программы, аллокирующие много кусков по ~10-100b, и освобождающие куски потом в произвольном порядке.

anonymous
()

>В А Ж Н О: Это характерно для mozilla/firefox/seamonkey/netscape под __Linux__

WinXP SP2, аналогичное поведение. Память не отдаёт в систему, кажется, вообще.

Dimentiy ★★
()
Ответ на: комментарий от anonymous

XZ

Бывало такое, что все табы закрыты, а размер потребляемой памяти переваливает за 100мегов (VM SIZE - ещё выше).

Чем это вызывается - меня ломало разбираться.

По моим наблюдениям на W2K бывает такое же поведение.
Течёт просто, как решето :(

Dimentiy ★★
()
Ответ на: комментарий от Dimentiy

Вот ещё радость...
Набрал сейчас "about:cache", получил:

-- cut --
Memory cache device

Number of entries: 651
Maximum storage size: 4096 KiB
Storage in use: 25654 KiB
Inactive storage: 0 KiB
-- end --

Используется для кэша в 6 раз больше, чем разрешено.
При этом открыто два простейших таба.
Пиздец какой-то.

Dimentiy ★★
()
Ответ на: комментарий от anonymous

Пустое :( Я туда репортил тривиальную багу, которуб уже несколько лет пофиксить не могут. Как-то в новостях обсуждали...

Сейчас вот работа с клипбордом отвалилась (Win32 версия)... То есть тупо "Copy" не помещает ничего в клипборд.

Кабы не скрапбук, давно бы выбросил ЭТО нафиг. Но скрапбук ВСЁ перевешивает. И нету альтернатив.

Dimentiy ★★
()

Насколько я знаю, сейчас glibc использует оба механизма: и через sbrk(), и через mmap(). Если идет запрос на выделение больших кусков памяти (больше 128К), то используется mmap(). Если меньше, то sbrk().

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

У mozilla наиболее вероятный размер запроса malloc() ~ 16b.

После закрытия ~30 табов malloc_stats() говорит:

Arena 0: system bytes = 41447424 in use bytes = 9261256 Arena 1: system bytes = 3837952 in use bytes = 149304 Total (incl. mmap): system bytes = 45285376 in use bytes = 9410560 max mmap regions = 1 max mmap bytes = 184320

Из ~40М динамической памяти только ~180K mmap()-нутые.

z11780
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.