LINUX.ORG.RU

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


0

0

В последнее время многие участники сообщества Mozilla, включая волонтёров и работников компании, помогают исправить ошибки, связанные с утечками оперативной памяти, и уменьшить её потребление веб браузером Firefox. Таким образом, появилась надежда, что в результате этих совместных усилий, Firefox 3 будет использовать меньше ОЗУ, чем Firefox 2, в особенности, если вы бродите по Интернету в течение долгого времени.

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

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Что выйдет - всё будет гут)

dx
()

Те жы яйцы только в профиль!

anonymous
()

Фаерфоксу нужен сборщик мусора и механизм исключений вместо кодов возврата. Там половину кода можно будет тогда выбросить.

Legioner ★★★★★
()

Ура FF перепишут на mono

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

Может быть, но я думаю что с этим разберутся - раз уж взялись :-)

dx
()

Попробовал это так называемое "неофициальное решение", вылетает с:
No running windows found
/usr/libexec/mozilla-launcher: line 119: 9199 Segmentation fault "$mozbin" "$@"
firefox-bin exited with non-zero status (139)

У кого-то работает?

А так тема интересная, может доведут до ума.

nevsky
()

>К сожалению, о старой ошибке, связанной с некорректным высвобождением памяти библиотекой glibс

А glibс уже исправили? В чём там проблема?

GladAlex ★★★★★
()

У меня неофиц. решение работает. Мозилла памяьть обратно отдаёт.

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

>А glibс уже исправили?

в аллокаторе.

>В чём там проблема?

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

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

>А glibс уже исправили? В чём там проблема?

Уже сходил по ссылке ;) - понятно

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

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

Legioner ★★★★★
()

Фаерфоксу надо на KHTML просто перейти :)

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

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

Все, что используют glibc, получается. Список огромный.

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

> А под виндой?? :-D

Все в порядке, так же как и в солярке. Кстати, в ней родимой и хоткеи в русской раскладке работают=)

Motiv_studenta ★★
()

Это получается, что любая программа, в которой есть вызов malloc жрёт память. Так?

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

Так что сейчас может начаться массовый переход на mmap?

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

>Это получается, что любая программа, в которой есть вызов malloc жрёт память. Так?

Ну если учесть, что маллок выделяет память, то ДА, безусловно жрет

anonymous
()

> Firefox

Прикольная программа. Я когда линукс себе в первый раз поставил как раз этой программой воспользовался. Чтобы зайти на opera.com и скачать оттуда нормальный браузер.

anonymous
()

У меня фф, бывает, потребляет очень много памяти - гиг, полтора.. Что самое обидное, так потребляет это не сколько он, сколько X-сервер - но по выходу из фф память X-сервер обычно возвращает (не всегда всю, потихонечку растет).

Например:

$ ps aux|grep Xorg root 7495 3.3 20.1 890732 415836 tty7 SLs+ Sep15 281:52 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 root 7522 0.0 20.1 890732 415836 tty7 SL+ Sep15 0:00 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7

$ ps aux|grep firefox user 8378 0.0 0.0 72464 972 ? S Sep15 0:00 /bin/sh /home/user/Software/Deployed/firefox/firefox user 8381 0.0 0.0 72464 960 ? S Sep15 0:00 /bin/sh /home/user/Software/Deployed/firefox/run-mozilla.sh /home/user/Software/Deployed/firefox/firefox-bin user 8386 2.2 12.2 525604 253164 ? Sl Sep15 188:14 /home/user/Software/Deployed/firefox/firefox-bin

Сейчас все хорошо, тормозов нет. Но никто не гарантирует, что завтра фф не сожрет несколько сот мегов, а иксы - гигабайтик оперативки. И тогда будут жуткие тормоза (памяти всего два гига - думал еще пару добавить, но потом решил, что маразм, из-за ff 4 гига держать, лучше перезапускать его иногда).

Что это такое и как это лечить?

anonymous
()

Мда, кнопку "предпросмотр" сделали, но настройка разбиения строк все так же сбивается при вводе неверного кода.. Когда пофиксят-то? :-/

У меня фф, бывает, потребляет очень много памяти - гиг, полтора.. Что самое обидное, так потребляет это не сколько он, сколько X-сервер - но по выходу из фф память X-сервер обычно возвращает (не всегда всю, потихонечку растет).

Например:

$ ps aux|grep Xorg
root 7495 3.3 20.1 890732 415836 tty7 SLs+ Sep15 281:52 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
root 7522 0.0 20.1 890732 415836 tty7 SL+ Sep15 0:00 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7

$ ps aux|grep firefox
user 8378 0.0 0.0 72464 972 ? S Sep15 0:00 /bin/sh /home/user/Software/Deployed/firefox/firefox
user 8381 0.0 0.0 72464 960 ? S Sep15 0:00 /bin/sh /home/user/Software/Deployed/firefox/run-mozilla.sh /home/user/Software/Deployed/firefox/firefox-bin
user 8386 2.2 12.2 525604 253164 ? Sl Sep15 188:14 /home/user/Software/Deployed/firefox/firefox-bin

Сейчас все хорошо, тормозов нет. Но никто не гарантирует, что завтра фф не сожрет несколько сот мегов, а иксы - гигабайтик оперативки. И тогда будут жуткие тормоза (памяти всего два гига - думал еще пару добавить, но потом решил, что маразм, из-за ff 4 гига держать, лучше перезапускать его иногда).

Что это такое и как это лечить?

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

>Попробовал это так называемое "неофициальное решение", вылетает с:
>No running windows found

А ты под офтопиком запускай)

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

> Чтобы зайти на opera.com и скачать оттуда нормальный браузер.

Кстати, опере от жора памяти ничего не поможет, так как туда malloc засунут статически.

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

> У меня фф, бывает, потребляет очень много памяти - гиг, полтора..

у меня в ноуте 512 метров оперативы. FF запущен постоянно, и постоянно шарюсь по инету. никогда не было проблем с памятью. FF хавает свои законные 50-70 метров и не жужжит. попробовал посмотреть на оперу - тормозное и глюкавое поделие. фтопку.

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

>Кстати, опере от жора памяти ничего не поможет, так как туда malloc засунут статически.

Ничего подобного: она памяти есть меньше, особенно если в КДЕ работаешь, в винде тоже, и память она возвращает сразу при закрытии страниц - проверено.

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

> Ничего подобного: она памяти есть меньше, особенно если в КДЕ работаешь, в винде тоже, и память она возвращает сразу при закрытии страниц - проверено.

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

anonymous
()

Никогда не страдал от этой проблемы. Интересно, к какой версии хоткеи пофиксят?

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

Забавно, но даже в комментариях новости, посвящённой борьбе с утечками памяти в ФФ, красноглазики пишут, что утечек нет. "Дурак -- это надолго"!

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

> даже в комментариях новости, посвящённой борьбе с утечками памяти в ФФ

Где это написано?

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

> Я конечно таких мощных тестов не проводил, но у меня она освобождала, проверял на своих страницах.

Она освобождает, например, если на странице была картинка, требующая >128K, так как под нее сразу вызывается mmap. Это относится ко всему, использующему glibс malloc.

anonymous
()

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

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

>Она освобождает, например, если на странице была картинка, требующая >128K, так как под нее сразу вызывается mmap. Это относится ко всему, использующему glibс malloc.

Они настолько плохи? Это же уже годами наблюдается. Массового перехода на mmap не наблюдается? Какая то новость была об mmap на ЛОР-е, кто-нибудь помнит?

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

>Интересно, что из этого выйдет

Как что? Firefox 3 Конечно.

>У меня фф, бывает, потребляет очень много памяти - гиг, полтора.. Что самое обидное, так потребляет это не сколько он, сколько X-сервер - но по выходу из фф память X-сервер обычно возвращает (не всегда всю, потихонечку растет).

Странно у меня 256 Mb и FF сносно работает, хотя иногда тормозит. В общем не жалуюсь, но сижу под Konqueroro-м.

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

> При чём тут mmap? Вы ещё на open перейти предложите. Или лучше на new[]

ЛОР во всей красе, етить.

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

>Прикольная программа. Я когда линукс себе в первый раз поставил как раз этой программой воспользовался. Чтобы зайти на opera.com и скачать оттуда нормальный браузер.

Очень жаль, что эта "прикольная программа" не рассчитана на то, чтобы ты мог ею убить себя :(

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

> Очень жаль, что эта "прикольная программа" не рассчитана на то, чтобы ты мог ею убить себя :(

Я же шутить пытаюсь. :) Сам, кстати, неоднократно пытался пересесть на FireFox. Ни разу не получилось.

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

> В общем не жалуюсь, но сижу под Konqueroro-м.

Аналогично, тоже подсел недавно - очень приятно и быстро в отличии от всех остальных. Ждём ещё лучше в КДЕ4.

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

>Фаерфоксу нужен сборщик мусора и механизм исключений вместо кодов возврата. Там половину кода можно будет тогда выбросить.

Firefox-у нужен pool-based allocator. И жёстко расписать, под что нужен каждый пул (например, можно выделять по пулу на страницу). При необходимости, пул отдаётся целиком, вне зависимости от того, в какой последовательности выделялясь память в данном пуле. Пояснения нужны? Пул -- кусок памяти _фиксированного_ размера, выделяемый через mmap, в котором располагается куча. Что-то вроде:

int pool_id = create_pool(size);
...
some_type *some_ptr = pool_malloc(pool_id, size);
...
...
destroy_pool(pool_id);
...
И всё, нету пула, вместе со всей, выделенной в нём памятью, списками блоков etc.

AsphyX ★★★
()

Прочитал: "работа по ускорению утечек памяти..."

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