[12309] вот и компиляй современный софт

＞компиляй
＞Пенёк-4, памяти всего гиг

Садомазо какое-то.

загнав в своппинг почти два гига

ты сам хоть понял свою проблему? жди мегабакса он тебе объяснит что нужен корка7 и 16 гигов рамы

Это жжжосткий свопинг, не 12309.

Все *.a распаковывались.

Суровые гентушники настолько суровы, что делают скриншоты фотоаппаратом :)

pf-kernel для эксперимента.

experiment failed

линковщик при make -j16 на вебките делает тоже самое. памяти больше нужно

Садомазо какое-то.

У меня на Pentium D и 1гб памяти гента нормально жила, так что ненадо. :)

А MAKEOPTS="-j1" хотя бы?

Ну этот ССЗБ еще и нехило нагрузил ее вдовесок.

Твоя ошибка заключается в количестве ОЗУ.

Дык линкёр всегда отжирал по 3—4 гига оперативы и свопа при сборке Firefox начиная где-то с 4-ой версии. На моём нетбуке с 1 ГиБ ОЗУ это вообще выливается в четырёхчасовой полный фриз всего с постоянным шуршанием винчестера, а 12309 тут вовсе ни при чём.

Ну этот ССЗБ еще и нехило нагрузил ее вдовесок.

Если поставить еще хотя бы 1 гиг оперативки то проблем быть не должно.

генту

Время удалять генту, генту сама не удалится.

так это же Firefox

Дык линкёр всегда отжирал по 3—4 гига оперативы и свопа при сборке Firefox начиная где-то с 4-ой версии.

4.2

собирал icecat пятой версии на 512MB ОЗУ.

Переходи на FreeBSD.

Нифига, он его сам нарисовал, как-то так http://www.youtube.com/watch?v=eKyO-uzp2Zk

Переходи на FreeBSD.

А что, во фре фаерфокс какой то другой? :)

компиляй
Пенёк-4, памяти всего гиг

Садомазо какое-то.

Ты не представляешь, сколько я компилял на Celeron-1700 с гигом оперативки, работающим в качестве десктопа. И никаких тормозов :)

А сейчас, на P4-3000 с двумя гигами — тем более.

Там что-то другое.

…

Да, если что,
PORTAGE_NICENESS=«7»
MAKEOPTS="-j2"
EMERGE_DEFAULT_OPTS="-vb --jobs=2 --load-average=3 --autounmask=n"

Ну и запускаю компиляцию с ionice -c3 emerge ...

firefox

Гм, а я думал така хрень тока при компиляции openoffice может происходить

дублирую мысль про скатывание половины свободного софта в СГ после 2008.

А у нас в слаке такими вещами Патрег занимается. Наш Б-х любит своих детишек и по-настоящему заботится о них. Такие дела.

4.2

собирал icecat пятой версии на 512MB ОЗУ.

И не отжирало 4 гига при линковке (с учётом свопа, естественно)? И что я делаю не так? Заделись секретом.

＞ionice -c3
Читер :}

Суровые гентушники настолько суровы, что делают скриншоты фотоаппаратом :)

Только после этого комментария я сходил по ссылке. Действительно, сурово :D

…

Очень рекомендую всем, следящим за быстродействием при нехватке ресурсов поставить gnome applet «Системный монитор» и включить в нём показ io-wait для CPU и заполнение памяти. Сразу будет видно, не хватает памяти или кто-то жёстко терзает винт:

http://img577.imageshack.us/img577/9324/selection084.png

Рекомендую для CPU поставить обычную, user-загрузку зелёным, nice — тёмным синим (типа, пофиг, есть она или нет), io-wait — красным.

…

Ну и выглядеть компиляция должна как-то так:

http://img232.imageshack.us/img232/4199/10090.png

Читер :}

А я все фоновые процессы, скорость которых мне не важна, так запускаю :) И демоны в том числе.

Может, поэтому #12309 никогда не видел? :D

какое ядро - похер
настраивай винстайл-своппинг
ну или докупи таки оперативы
ибо линковщику при сборке лисы нужно дохера оперативы

ну и осиль уже приоритеты

Только после этого комментария я сходил по ссылке. Действительно, сурово :D

А подумать? Если запускать какой-нибудь скрин-шотер и сохранять картинку, система сознание потеряет.

при сборке Firefox начиная где-то с 4-ой версии

(глядя в логи через genlop)

По 4-ю версию включительно, Firefox собирался на 4-м пне за 3-5 минут. Потому что все потроха были в xulrunner, который и собирался 13-15 минут. 4-я версия ничем примечательна в сравнении с 3-й не была.

В 5-й версии и далее разделение на firefox и xulrunner убрали, firefox стал собираться за 2 часа.

PORTAGE_IONICE_COMMAND=«ionice -c 3 -p \$\PID»
PORTAGE_NICENESS=19
MAKEOPTS="-j4"

не влияют на аналогичные тормоза

Если запускать какой-нибудь скрин-шотер и сохранять картинку, система сознание потеряет.

Ну, я просто с таким не сталкивался :) Фотографировал только всякие кернел-паники, да ошибки загрузки :)

с релиза 5-ки
бетки собирались ещё по минуте

PORTAGE_IONICE_COMMAND

И такое работает? Раньше не было. Погляжу

PORTAGE_NICENESS=19

Слишком низкий приоритет — опасно ставить. Система, загруженная другим фоновым процессом может совсем не давать времени на компиляцию. Я даже с +10 ушёл на +7 :)

MAKEOPTS="-j4"

А вот это — чревато. Если ещё и --jobs будет хотя бы 2, это в пике уже до 8 процессов компиляции. Начнёт какой-нить kde* собираться, выжрет всю память.

И не вижу EMERGE_DEFAULT_OPTS. Там актуальны --jobs и --load-average

Система, загруженная другим фоновым процессом может совсем не давать времени на компиляцию.

о_О?
на 10-ке как раз нормально

бетки собирались ещё по минуте

Походу, они были замаскированы. У меня после www-client/firefox-4.0.1-r1 сразу www-client/firefox-5.0 идёт. Хотя firefox в ~arch и обновляюсь довольно регулярно.

хз-хз

     Mon May 16 12:51:57 2011 >>> www-client/firefox-4.0.1-r1
       merge time: 1 minute and 18 seconds.

     Thu May 26 20:56:04 2011 >>> www-client/firefox-5.0_beta2
       merge time: 1 minute and 5 seconds.

     Sat Jun 11 00:15:06 2011 >>> www-client/firefox-5.0_beta5
       merge time: 54 seconds.

     Fri Jun 24 15:36:51 2011 >>> www-client/firefox-5.0
       merge time: 28 minutes and 55 seconds.

на 10-ке как раз нормально

Да, но не на +19 :) На 10 жить можно, хотя, как я писал, сам на +7 ушёл :) На +10..+15 всякие многочасовые бэкапы висят и т.п.

Да, скорее всего были замаскированы:

     Thu May  5 15:05:00 2011 >>> www-client/firefox-4.0.1
       merge time: 9 minutes.

     Fri May 20 05:35:32 2011 >>> www-client/firefox-4.0.1-r1
       merge time: 5 minutes and 12 seconds.

     Sun Jun 26 13:32:50 2011 >>> www-client/firefox-5.0
       merge time: 3 hours, 10 minutes and 53 seconds.

     Tue Jun 28 05:13:35 2011 >>> www-client/firefox-5.0-r1
       merge time: 2 hours, 14 minutes and 6 seconds.

В 5-й версии и далее разделение на firefox и xulrunner убрали

ЕМНИП, ещё в 4-ой версии оно было то монолитным, то раздельным (разные ебилды встречал), но могу и ошибаться — давно было, а версии штампуют с непомерной скоростью, всё и не запомнить.

xulrunner, который и собирался 13-15 минут

Да ладно, это где ж такой 4-ый пень взять, чтобы xulrunner собирался по 15 минут? На моём 4-ом пне с 3.2 ГГц он уж точно больше часа собирался (в логи не посмотрю — этот комп сейчас выключен).

firefox стал собираться за 2 часа.

Да, компилируется он где-то пару часов, но потом в дело вступает ld — и полный фриз часа на 3, даже по ssh не достучаться. Оперативы у меня 1 гигабайт, фризится из-за жёсткого своппинга, и как заставить ld жрать меньше памяти, я не представляю. Если есть какие-то способы, кроме добавления 8 гигабайт ОЗУ, буду рад выслушать.

настраивай винстайл-своппинг

Это что?

sysctl vm.swappiness=100

sysctl vm.swappiness=100

И как это может помочь, если объём сжираемой памяти ld всё равно больше размера ОЗУ? Тогда будет ещё больше обращений к винчестеру, что ещё больше замедлит линковку.

4.2

собирал icecat пятой версии на 512MB ОЗУ.

И не отжирало 4 гига при линковке (с учётом свопа, естественно)?

не отжирало. Так как вместе со свопом у меня от силы 1.2гига было.

И что я делаю не так? Заделись секретом.

может дело в 64-битности?

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

Да ладно, это где ж такой 4-ый пень взять, чтобы xulrunner собирался по 15 минут?

В зависимости от занятости машины (это было ещё NICE +10, да ещё процессор нечищенный, в throttling при перегреве сваливался):

     Fri Sep 17 10:39:29 2010 >>> net-libs/xulrunner-1.9.2.9
       merge time: 1 hour, 6 minutes and 14 seconds.

     Sat Sep 18 10:43:45 2010 >>> net-libs/xulrunner-1.9.2.9-r1
       merge time: 14 minutes and 29 seconds.

     Wed Oct 13 20:17:37 2010 >>> net-libs/xulrunner-1.9.2.9-r1
       merge time: 14 minutes and 49 seconds.

     Wed Oct 27 03:59:38 2010 >>> net-libs/xulrunner-1.9.2.11
       merge time: 1 hour, 18 minutes and 21 seconds.

     Thu Nov  4 20:22:57 2010 >>> net-libs/xulrunner-1.9.2.12
       merge time: 13 minutes and 39 seconds.

     Sat Dec  4 15:20:56 2010 >>> net-libs/xulrunner-1.9.2.12-r1
       merge time: 56 minutes.

Естественно, речь только про 1.9.x, в 5-м Firefox xulrunner-2 тоже по полтора — два часа стал собираться :)

Да, компилируется он где-то пару часов, но потом в дело вступает ld — и полный фриз часа на 3

Нет. У меня честное время merge, выше лог genlop приводил. Никаких различий между компиляцией и линковкой не замечал.

даже по ssh не достучаться

Ужасы какие-то. А я спокойно во время фонового emerge хожу по сайтам, работаю, смотрю фильмы… :)

Оперативы у меня 1 гигабайт

Вот тут — может быть. У меня — 2Гб и иногда, особенно, когда Опера метров 500..700 выжрет, на буфера совсем мало остаётся. На гигабайте, соответственно, совсем тесно будет.

Если есть какие-то способы, кроме добавления 8 гигабайт ОЗУ, буду рад выслушать

К.О. тут советует запускать компиляцию в один поток и в одну работу, с низкоприоритетными nice/ionice и поубивать/понастроить всё, что жрёт память. Скажем, в тех же браузерах в настройках урезать кеш в ОЗУ. Может быть DE выбрать поэкономнее. И т.п.

кстати - лучше через dd + tmpfs
ещё и скорость увидишь, дабы не было «это субъективно» и прочего флуда

короче - чем меньше сей параметр, тем больше тормоза при своппинге

Я, кстати, на дефолтовые 60 перешёл не так давно. А то в памяти висит подолгу то, что в своп скинуть можно и потратить на буфера/кеши :) Чем больше свободной памяти под буфера, тем плавнее система работает.

а я отрубил нахрен своп :3
ибо даже 8 гигов при 6.3 в tmpfs для сборки хватает для всего

а я отрубил нахрен своп :3

На двух гигах он даёт очень заметную прибавку к скорости. Даже на 3Гб ещё заметно. Только где-то на 4Гб можно сносить, если реально не нужен :)

А 8Гб у меня только на серверах :D

а что пыхтон делает?