Вы здесь

Главная › Форум › Gentoo Linux › Система portage

tmpfs /var/tmp/portage

23 февраля, 2011 - 02:59 — torovich

Всем привет!
Решил ускорить на сврём нетбуке компиляцию по http://ru.gentoo-wiki.com/wiki/%D0%A3%D1%81%D0%BA%D0%BE%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_portage_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_tmpfs.
Добавил в fstab:

tmpfs   /var/tmp/portage        tmpfs   size=1000M,mode=0777 0 0
tmpfs   /tmp    tmpfs   defaults        0 0

Решил проверить. Вот что получилось.

# df -t tmpfs
Файловая система     1K-блоков      Исп  Доступно  Исп% смонтирована на
rc-svcdir                 1024       112       912  11% /lib/rc/init.d
udev                     10240       264      9976   3% /dev
shm                     510352         0    510352   0% /dev/shm
tmpfs                  1024000         0   1024000   0% /var/tmp/portage
tmpfs                   510352       152    510200   1% /tmp


# genlop -t qutim
 * net-im/qutim

     Sat Nov 20 02:10:50 2010 >>> net-im/qutim-0.2.0-r3
       merge time: 27 minutes and 23 seconds.

     Tue Dec  7 19:31:32 2010 >>> net-im/qutim-0.2.0-r3
       merge time: 24 minutes and 31 seconds.

     Wed Feb 23 02:43:37 2011 >>> net-im/qutim-0.2.0-r3
       merge time: 25 minutes and 37 seconds.


# genlop -t xneur gxneur
 * x11-misc/xneur

     Thu Nov 25 17:27:25 2010 >>> x11-misc/xneur-0.9.9
       merge time: 2 minutes and 45 seconds.

     Fri Nov 26 11:56:44 2010 >>> x11-misc/xneur-0.9.9
       merge time: 2 minutes and 43 seconds.

     Mon Nov 29 17:41:59 2010 >>> x11-misc/xneur-0.9.9
       merge time: 2 minutes and 39 seconds.

     Sat Feb 19 06:14:53 2011 >>> x11-misc/xneur-0.9.9
       merge time: 2 minutes and 45 seconds.

     Wed Feb 23 02:13:47 2011 >>> x11-misc/xneur-0.9.9
       merge time: 2 minutes and 44 seconds.

 * x11-misc/gxneur

     Thu Nov 25 17:20:36 2010 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 56 seconds.

     Fri Nov 26 11:58:31 2010 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 47 seconds.

     Mon Nov 29 17:43:44 2010 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 45 seconds.

     Tue Dec  7 11:23:46 2010 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 44 seconds.

     Sat Feb 19 06:18:43 2011 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 51 seconds.

     Sun Feb 20 02:31:14 2011 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 56 seconds.

     Wed Feb 23 02:15:34 2011 >>> x11-misc/gxneur-0.9.9
       merge time: 1 minute and 47 seconds.

Жирным выделена компиляция с tmpfs. Вопрос: "Где уменьшение времени компиляции?"

Форум: 
Система portage
23 февраля, 2011 - 03:52 — SysA

А памяти сколько?
Посмотрите статистику - полагаю у вас все в своп ушло... :)

23 февраля, 2011 - 05:15 — willy

Пардон, а при чём тут tmpfs и время компейляции?
Насколько я понимаю, tmpfs позволяет ускорить распаковку тарболлов, плюс уменшить время доступа к исходным файлам, но
время компиляции - в прямой зависимости от мощности камня.

23 февраля, 2011 - 10:49 — torovich

Согласен, неправильно написал. Но смысл в том, что в wiki написано ускорение установки, переустановки, обновления на 10%. При обновлении одного пакета - роли не играет, а при обновлении мира - уже существенно.

23 февраля, 2011 - 12:49 — SysA

FYI: общее время компиляции уменьшается за счет существенного сокращения дискового ввода/вывода при правильном выборе и конфигурации файловых систем.

23 февраля, 2011 - 14:21 — Theli

willy написал:
Пардон, а при чём тут tmpfs и время компейляции?

присоединяюсь! тоже не понимаю этого ))

даже при стандартной настройке, все i/o кешируются в памяти, что равносильно tmpfs ;) я использую tmpfs просто для уменьшения i/o, так сказать для более долгой жизни винта )) особенно это полезно тем, у кого ssd, имхо... а для скорости лучше использовать distcc или ccache ;)

23 февраля, 2011 - 20:29 — Spoiler

Theli написал:
все i/o кешируются в памяти

Во-первых, "откуда дровишки"? :-) оно IMHO?
Во-вторых, при компиляции (точнее - при трансляции) много пишется в объектные файлы, по большому счёту являющимися временными, соотв., располагая их в tmpfs, реальных дисковых операций производится значительно меньше. Это ощутимо даже "органолептически" (по светодиоду), невооружённым глазом наблюдая активность дисковой подсистемы - разницу не заметить просто невозможно

Цитата:
для скорости лучше использовать distcc или ccache

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

—

Мы тоже не всего читали Шнитке!.. © В. Вишневский

23 февраля, 2011 - 22:35 — Theli

Spoiler написал:
Во-первых, "откуда дровишки"? :-) оно IMHO?

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

Spoiler написал:
Во-вторых, при компиляции (точнее - при трансляции) много пишется в объектные файлы, по большому счёту являющимися временными, соотв., располагая их в tmpfs, реальных дисковых операций производится значительно меньше. Это ощутимо даже "органолептически" (по светодиоду), невооружённым глазом наблюдая активность дисковой подсистемы - разницу не заметить просто невозможно

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

Spoiler написал:
ccache может помочь только при повторной компиляции или (иногда) при обновлении в виде патча. При обычном обновлении из нового тарболла (и тем более при первичной инсталляции), ccache не только не помогает, но даже мешает, увеличивая кол-во дисковых операций для сохранения результатов (которые с высокой степенью вероятности никогда не понадобятся)

я в курсе... каждой программе свой частный случай для применения ;)

23 февраля, 2011 - 22:46 — evadim

Theli написал:

Spoiler написал:
Во-вторых, при компиляции (точнее - при трансляции) много пишется в объектные файлы, по большому счёту являющимися временными, соотв., располагая их в tmpfs, реальных дисковых операций производится значительно меньше. Это ощутимо даже "органолептически" (по светодиоду), невооружённым глазом наблюдая активность дисковой подсистемы - разницу не заметить просто невозможно

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

Это теоритически, а на практике, при 8 гигах оперативы ещё как моргала, до переноса tmpfs в shm.
Что до swapiness, то он с довольно давно автоматически меняется ядром, да и памяти оперативной у ТС аж цельный гигабайт...

23 февраля, 2011 - 23:23 — Spoiler

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

То, о чём вы говорите - не кэширование данных, а кэширование команд I/O, это работа планировщика,.никоим образом не уменьшающая кол-во дисковых операций, а лишь группирующая и распределяющая их во времени. К сож., при этом даже в случае, когда по мнению GCC запись уже не актуальна, она всё равно будет выполнена, поск-ку команда контроллеру была в своё время выдана и закэширована

Цитата:
если оперативы достаточно и параметр swapiness приближен к нулю, то, если кешированный файл не был выдавлен из оперативы, то реального дискового обращения и не произойдет

Шалите. Так произойдёт как раз в том случае, если, как вы называете, "реальное дисковое обращение" обращается к tmpfs, поск-ку в памяти приложения (конкретно - GCC) происходит манипуляция "сырыми данными" во внутреннем представлении, а все результаты этих манипуляций - это и есть объектные файлы, в обязательном порядке выводятся наружу (на диск или tmpfs) для того, чтобы их можно было использовать в своих произвольных целях тому, кто дал задание на сборку. При чём выводятся не моментально в готовом виде, а открываются на последовательную запись и обращений к ним множество (что также действительно и для лога сборки)... Это уже portage всё подчищает - ему оно не нужно, а если будете компилить вручную - увидите, в этом случае достаточно легко помониторить...

Цитата:
каждой программе свой частный случай для применения

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

—

Мы тоже не всего читали Шнитке!.. © В. Вишневский

24 февраля, 2011 - 13:13 — Theli

Spoiler написал:
конкретно для ccache, который вы рекомендуете для ускорения

стоп-стоп-стоп!!! если я его назвал, это еще не значит, что я его рекомендую!!!

24 февраля, 2011 - 03:53 — torovich

Спасибо за ликбез. distcc не использую, хотя и есть другой компьютер но там Windows, жена и дети. ccache тоже не включен.

23 февраля, 2011 - 11:02 — torovich

Памяти 1 гиг. При работе emerge смотрел df. tmpfs /var/tmp/portage - используется 5%. Своп вообще не используется (есть но 0% использования). Оперативки использовано процентов 15. Специально выключил все программы.

23 февраля, 2011 - 11:24 — evadim

Думаю с гигом ОЗУ и с таким процессором оно не скажется сильно, у меня вот вынос /tmp на usb-hdd не особенно затормозил сборку, видать дальше просто некуда тупить.

23 февраля, 2011 - 12:54 — SysA

1. Предлагаю вынести весь /var/tmp/ в tmpfs
2. Смотреть/писать sar'oм во время компилюции и покажите сюда.

24 февраля, 2011 - 03:56 — torovich

С sar'ом пока не разобрался. В каком он пакете?

24 февраля, 2011 - 09:51 — SysA

app-admin/sysstat

Там же есть еще интересная штучка, которая вам может пригодиться: iostat

24 февраля, 2011 - 20:46 — torovich

Сделал так:

# df
Файловая система     1K-блоков      Исп  Доступно  Исп% смонтирована на
rootfs                 2063504    494884   1463800  26% /
/dev/root              2063504    494884   1463800  26% /
rc-svcdir                 1024       112       912  11% /lib/rc/init.d
udev                     10240       264      9976   3% /dev
shm                     510352         0    510352   0% /dev/shm
/dev/sda5            103210940  83060880  14907252  85% /home
/dev/sda6             20641788   8016488  11576660  41% /usr
/dev/sda7             18577596   1578416  16055364   9% /var
tmpfs                   510352         0    510352   0% /var/tmp
tmpfs                   510352       108    510244   1% /tmp

Ядро компилится пол часа. Думаю для n270 - это нормально.

24 февраля, 2011 - 21:32 — _SerEga_

ядро компилиться не /var/tmp/, а в/usr/src/linux

23 февраля, 2011 - 11:28 — alius

Выставлен ли в make.conf -pipe и ccache?
http://forums.gentoo.org/viewtopic-p-6233551.html
http://www.gentoo.ru/node/13222

—

vanitas vanitatum et omnia vanitas

23 февраля, 2011 - 13:34 — evadim

ccache даёт выгрыш только при частых пересборках одинаковых пакетов, но вот затормаживает первую сборку всегда. Его применение в обычных системах только затормаживает процесс.

23 февраля, 2011 - 20:13 — slepnoga

+10

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

24 февраля, 2011 - 01:49 — alius

Я имел ввиду, если в make.conf выставлены -pipe и ccache, они могут быть причиной увеличения времени сборки в tmpfs.

—

vanitas vanitatum et omnia vanitas

24 февраля, 2011 - 10:37 — _SerEga_

как -pipe может увеличивать время сборки?

24 февраля, 2011 - 12:57 — alius 

-pipe – передавать промежуточные данные по конвейеру (в оперативной памяти,а не через винт)

http://optimization.hardlinux.ru/?page_id=34

без pipe в tmpfs быстрее будет, если флаги не -O3…

http://optimization.hardlinux.ru/
Насколько я понимаю, -pipe убыстряет копиляцию на харде, сохраняя промежуточные результаты в оперативке. При tmpfs компиляция и так происходит в оперативке, так что -pipe, имхо, нецелесообразен. Поправьте меня, если я ошибаюсь.

—

vanitas vanitatum et omnia vanitas

24 февраля, 2011 - 13:08 — _SerEga_

Это самое подробное обоснование(по вашей ссылке):

если в памяти, лучше отключить, лишние операции по копированию, лишняя память, без pipe в tmpfs быстрее будет, если флаги не -O3…

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

25 февраля, 2011 - 12:21 — alius

однако..

Fri Feb 25 10:44:57 2011 >>> gnome-base/nautilus-2.32.2.1
       merge time: 1 minute and 51 seconds.

     Fri Feb 25 10:47:32 2011 >>> gnome-base/nautilus-2.32.2.1
       merge time: 1 minute and 42 seconds.

     Fri Feb 25 10:50:43 2011 >>> gnome-base/nautilus-2.32.2.1
       merge time: 1 minute and 43 seconds.

1 -- tmpfs, без -pipe
2 -- tmpfs, с -pipe
3 -- без tmpfs, c -pipe

Потом я сменил -О3 на -О2:

Fri Feb 25 11:12:55 2011 >>> gnome-base/nautilus-2.32.2.1
       merge time: 1 minute and 52 seconds.

     Fri Feb 25 11:14:48 2011 >>> gnome-base/nautilus-2.32.2.1
       merge time: 1 minute and 40 seconds.

1 -- tmpfs, -O2 -pipe
2 -- tmpfs, -O2, без -pipe

Делайте выводы, господа)

—

vanitas vanitatum et omnia vanitas

25 февраля, 2011 - 15:37 — Spoiler

alius написал:
Делайте выводы

А ск-ко у вас ядер и в ск-ко потоков происходит сборка?

—

Мы тоже не всего читали Шнитке!.. © В. Вишневский

25 февраля, 2011 - 22:27 — alius

Intel Core i330m, 2 ядра физических но 4 виртуальных. MAKEOPTS="-j4"
Может протестируете у себя? Чтоб картина была более полной.

—

vanitas vanitatum et omnia vanitas

25 февраля, 2011 - 22:43 — _SerEga_

Желательно тестировать, на чем, то более крупном c временем сборки минут 10-20-30

7 марта, 2011 - 09:40 — Fracta1L

alius написал:
-pipe – передавать промежуточные данные по конвейеру (в оперативной памяти,а не через винт)

http://optimization.hardlinux.ru/?page_id=34

без pipe в tmpfs быстрее будет, если флаги не -O3…

http://optimization.hardlinux.ru/
Насколько я понимаю, -pipe убыстряет копиляцию на харде, сохраняя промежуточные результаты в оперативке. При tmpfs компиляция и так происходит в оперативке, так что -pipe, имхо, нецелесообразен. Поправьте меня, если я ошибаюсь.

Всегда думал, что -pipe относится к самим бинарникам, а не к компиляции. Даже если это не так - "нецелесообразен" не означает "вреден". Поменьше верь тому, что мегабакс там пишет.

24 февраля, 2011 - 04:01 — torovich

-pipe есть (ставил из английского howto для atom n270), ccashe нет (думаю не нужен).

25 февраля, 2011 - 12:11 — alius

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

umount /var/tmp/portage && mount -o bind /home/portage-tmp/ /var/tmp/portage/

—

vanitas vanitatum et omnia vanitas

2 марта, 2011 - 01:04 — torovich 

     Tue Mar  1 22:51:58 2011 >>> app-text/xchm-1.18
       merge time: 2 minutes and 5 seconds.

     Tue Mar  1 22:58:49 2011 >>> app-text/xchm-1.18
       merge time: 2 minutes and 3 seconds.

1. c tmpfs
2. без ...

2 марта, 2011 - 07:47 — draft3r

А я бы из всего этого сделал бы вывод такой: гоняемся за копейками, а теряем рубли ..... другое дело что в процессе "погони" хоть "согрелись" тем самым уменьшив "лишнюю" нагрузку на носитель.....
ЗЫ в пакетах где выйгрышь в несколько секунд - результат смешон до слез, а с такими пакетом как ООО : из области часом больше - часом меньше....да еще и разово=)
Поэтому я для себя первичным критерием сделал снять лишнюю" нагрузку на носитель..

—

知る者は言わず言う者は知らず
"Бабло, побеждает даже зло"

2 марта, 2011 - 11:15 — valet2valet

Цитата:
Поэтому я для себя первичным критерием сделал снять лишнюю" нагрузку на носитель..

Совершенно верно и правильно. На время компиляции существенно не влияет вынос каталога для сборки в tmpfs.

3 марта, 2011 - 01:26 — torovich

Я еще сделал так:
/var/lib/portage/world

...
app-emulation/virtualbox-bin
...
app-office/openoffice-bin
...
www-client/firefox-bin
...

Очень много времени экономит.
А tmpfs пусть остается как есть.

7 марта, 2011 - 09:42 — Fracta1L

torovich написал:
Всем привет!
Вопрос: "Где уменьшение времени компиляции?"

Ускорение компиляции заметно только на тяжёлых пакетах. Это зелёным по чёрному написано в хэндбуке.

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal