LINUX.ORG.RU
решено ФорумTalks

[firefox4] RAM, HUGETLB, WTF?


0

4

Четвёртый огнелис всегда ел достаточно памяти. Поскольку у меня RAM было в избытке, решил скормить ему ещё больше памяти двухмегабайтными страницами и попробовать ускорить этим. В итоге в top сразу после запуска:

20147 x3al 25 5 885m 91m 50m S 2 2.4 0:02.96 firefox

x86-64, гента, остальное практически не трогал. Куда делся жир? Почему он потреблять настолько меньше памяти? На глаз особой разницы в скорости не заметил.

Желающим воспроизвести:

$>zgrep HUGE /proc/config.gz 
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
$>/sbin/sysctl vm.nr_hugepages # может не увеличиться при большом аптайме, на каждую большую страницу нужно 512-1024 непрерывных обычных
vm.nr_hugepages = 200
$>mount|grep tlb
hugetlbfs on /var/tlbfs type hugetlbfs (rw)
$>ls -ld /var/tlbfs 
drwxrwx--- 2 root libhuge 0 Apr 23 01:27 /var/tlbfs
$>groups
wheel audio video users vboxusers x3al libhuge
$>LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes firefox&
…
HugePages_Free: 111 (из 200) в /proc/meminfo намекают, что libhugetlbfs работает.

★★★★★

Надо попробовать. Вчера поставил 4-й, потребление еще возросло, теперь при 15 вкладках сжирает 250 Мб >_<

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

>теперь при 15 вкладках сжирает 250 Мб >_<
18 вкладок, 165 метров. Аптайм уже заметный.
Если x86 без PAE, то стоит выделять меньше больших страниц. На x86 1 страница = 4 Мб, на x86-64 — 2 Мб.

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

Почему с hugetlb он жрёт в ~2 раза меньше? Я всегда думал, что это слегка увеличит потребление RAM.

x3al ★★★★★
() автор топика

хм...интересно:
без

[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  2919 17.6  1.7 512004 71264 pts/1    SNl+ 12:18   0:00 firefox
megabaks  3118  0.0  0.0   5616   816 pts/3    SN+  12:18   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  3393 17.4  1.6 511980 69016 pts/1    SNl+ 12:18   0:00 firefox
megabaks  3560  0.0  0.0   5616   816 pts/3    SN+  12:18   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  3765 21.7  1.7 512272 71096 pts/1    SNl+ 12:18   0:00 firefox
megabaks  3886  0.0  0.0   5616   812 pts/3    SN+  12:18   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $
с
[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  6304 21.5  1.3 490904 57492 pts/1    SNl+ 12:20   0:00 firefox
megabaks  6455  0.0  0.0   5616   824 pts/3    SN+  12:20   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  6694 28.6  1.4 490880 58928 pts/1    SNl+ 12:20   0:00 firefox
megabaks  6817  0.0  0.0   5616   820 pts/3    SN+  12:20   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $ ps aux | grep firefox
megabaks  7139 21.2  1.0 488780 43324 pts/1    SNl+ 12:20   0:00 firefox
megabaks  7305  0.0  0.0   5616   824 pts/3    SN+  12:20   0:00 grep --colour=auto firefox
[ megabaks@desktop ] ~ $

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

так некоторые и про prelink думали совсем недавно

megabaks ★★★★
()

а хромой воистину хромой

ERROR: ld.so: object 'libhugetlbfs.so' from LD_PRELOAD cannot be preloaded: ignored.
[ root@desktop ] megabaks # grep -i huge /proc/meminfo 
AnonHugePages:     36864 kB
HugePages_Total:    1000
HugePages_Free:     1000
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
[ root@desktop ] megabaks #

megabaks ★★★★
()

>CONFIG_TRANSPARENT_HUGEPAGE=y

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y


Хммм...

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

Спасибо, это я тупло, в том мануале оно называлось /hugepages

Копипаста для таких же дебилов как я, которые не помнят, как делать группы

groupadd libhuge
chgrp libhuge /libhugetlbfs 
chmod 770 /libhugetlbfs
usermod -aG libhuge username

Алсо, поделюсь результатами:

+-------+-------------+--------------+-----------+
|       | Virtual mem | Resident mem |  Memory   |
+-------+-------------+--------------+-----------+
|  до   |   1.3 GiB   |  646.9 MiB   | 629.7 MiB |
+-------+-------------+--------------+-----------+
| после |   1.4 GiB   |  374.2 MiB   | 368.0 MiB |
+-------+-------------+--------------+-----------+    

Но странно:

$ grep -i huge /proc/meminfo 
AnonHugePages:     24576 kB
HugePages_Total:     285
HugePages_Free:      140
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
То есть, захьюджилось только 290 MiB. Занима-ательно… Хотя у меня тут ещё и ошибок повылезало
error: line XXX: multiple definitions of an affix flag
Где ХХХ число от 517 до 3523, всего штук ≈150.

Deleted
()

хотел только что похвастаться, что firefox кушает 50мб из 2гб, но тут понял, что firefox стоит версии 3.5.сколько-то

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

>захьюджилось только 290 MiB.
shared ram и память на код — в обычных сегментах если больше ничего не делать. Собственно, я рассчитывал, что будет чуть быстрее работа огнелиса с используемой им RAM (он же не просто так её ест, или?).

Рабочая гипотеза: malloc в libhugetlbfs не такой пессимистичный, как в glibc и не овераллокатит (как минимум до такой степени). Тогда firefox должен затормозиться на открытии больших страниц/картинок/whatever, где он не может сразу оценить объём нужной RAM. Но /me не знает, как это бенчмаркнуть.

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

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

Deleted
()

Хм... У меня запуск с одной вкладкой и различие по памяти двухкратное. 111 МБ без и 56 МБ с hugetlbfs. Джента 64 бита.

Lumi ★★★★★
()

Так и не понял, почему firefox4 похудел, но оставлю таким.
Включил LDFLAGS="-lhugetlbfs -ldl" для файрфокса и ещё некоторой мелочи и глобально экспортировал HUGETLB_MORECORE=yes, всё равно его подхватит только слинкованное с hugetlbfs.
Минусов и просаживаний в производительности не обнаружено, впрочем, особых плюсов тоже.
CONFIG_TRANSPARENT_HUGEPAGE=y для эффекта необязательно, а тем более CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y (может глобально повысить потребление памяти, включение делает AnonHugePages ненулевым). Но у меня серьёзный избыток RAM → пока оставлю.

Для тех, кто не в курсе: hugetlb делался для БД, java и виртуальных машин. Собственно, они умеют hugetlb без костылей вроде libhugetlbfs. Теоретически это повышает производительность при интенсивной работе с RAM процентов на 10, но не везде и сильно зависит от процессора. К снижению потребления RAM теоретически не имеет никакого отношения. Тем более эффект проявился только у firefox4 (у thunderbird 3.1, к примеру, особых изменений нет).

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

>Так и не понял, почему firefox4 похудел, но оставлю таким.
Он не похудел. ps aux и top вообще не видят занятую libhugetlbfs RAM.
Оставляю всё как есть, поскольку

у меня серьёзный избыток RAM

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