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

Я думал, что генту ставят на систему, в какой есть как минимум i3.

Гигабайт оперативы? emerge -v firefox-bin

Хотя, даже мой нетбук справляется :D

а я думал таких глупых ботов давно перебанили
а он ещё и звезду нафлудить смог...

Я думал, что генту ставят на систему, в какой есть как минимум i3.

http://balancer.ru/img/forums/0704/toshka.png

:) Правда, это кросс-компиляция.

А самая слабая машина, на которой Gentoo у меня автономно стояла, была Pentium 233MMX/32RAM/4Gb HDD. Но там она не долго стояла :)

Массово и постоянно Gentoo использовалась, где-то, с уровня Pentium2-500 с 512Мб.

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

Вряд ли это на что-то сильно влияет. У меня не 64-битная система, так что даже потребление памяти меньше должно быть.

сравни тормоза

ОК, я обязательно попробую выставить swappiness в 100, когда выйдет новый Firefox. Если не зафризится, как это обычно бывает, то я это сразу замечу.

а можно не ждать и потратить порядка 10 минут прямо здесь и сейчас

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

Я тоже, но только не во время линковки Firefox.

К.О. тут советует запускать компиляцию в один поток

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

в одну работу

Это у меня всегда так.

с низкоприоритетными nice/ionice

У меня так:

PORTAGE_NICENESS=«5»

PORTAGE_IONICE_COMMAND=«ionice -c 3 -p \${PID}»

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

По сравнению с ld всё остальное вообще ничего не жрёт :). Тут плюс-минус 200 метров роли не сыграют. $PORTAGE_TMPDIR перед сборкой firefox я отмонтирую от tmpfs, иначе всё совсем плохо. BTW, OOM-killer считал, что надо убивать именно ld, а не что-либо другое, пока я не добавил свопа.

а можно не ждать и потратить порядка 10 минут прямо здесь и сейчас

Сейчас это точно не буду делать, в лучшем случае завтра. И мне же важен конечный результат — чтобы не было фриза при линковке firefox, поэтому проверять лучше в реальных условиях, но эксперимент с dd в tmpfs тоже проведу.

не важно каким образом ты получишь своппинг
потому не отмазывайся, а делай
это приказ! :3

Сделаю завтра вечером. Сейчас на ночь глядя уже впадлу что-нибудь делать.

зато флудить горазд :3

Вот фото: http://plasmon.rghost.ru/36728661.image ... а команда жрет 600+ (она и выделена в htop: 613M RES), при этом проц почти не жрется, так что наблюдаем типичный 12309

Это не 12309, это самый обычный уход в свап. На фотке линковка (для буквоедов — «компоновка»). Она всегда жрет до черта оперативки (особенно в этом нашем GNU).

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

всмысле сама компиляция будет идти медленнее? это не страшно, я редко собираю слишком уж много всего сразу. время не особо критично, «бесшумность» сборки важнее

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

оно установлено с учётом distcc. кстати, вопрос в тему: чтобы в этом месте всегда была адекватная цифра - всякий раз при использовании distcc нужно править значение руками?

Начнёт какой-нить kde* собираться, выжрет всю память.

при непосредственно компиляции я проблем не замечал, вся прелесть заключается в жутком 12309 при работе ld

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

отсутствует, попробую при случае

http://www.linux.org.ru/forum/general/7446581?cid=7447510
может пригодится...

«зачем компилять?», «сноси генту!» и «переходи на арч!»

Спасибо, что упростил.

Это не 12309, это самый обычный уход в свап.

разве причина не может быть общей?

Cancellor

А у нас в слаке такими вещами Патрег занимается.

не, ну почему сразу Патрег? Я собирал фф. Могу сказать, что на 512 он в принципе не соберётся, на 1024 будет собираться годами, а вот на 1.5Гб нормально пока собирается (с каждой версией всё хуже и хуже).

dikiy

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

ну что поделать... Всё меняется. Не в лучшую сторону.

не, ну почему сразу Патрег? Я собирал фф. Могу сказать, что на 512 он в принципе не соберётся, на 1024 будет собираться годами, а вот на 1.5Гб нормально пока собирается (с каждой версией всё хуже и хуже).

мдя. Этот тред отбил у меня охоту собирать icecat 10.0 под athlon-xp :(

WTF!?

gentoo_root

и как заставить ld жрать меньше памяти, я не представляю.

нет никаких способов. И полтора гига пока хватает. (хотя я вроде только 9ку собирал. Обычно бинарники юзаю). Идите в магазин, и купите ещё гиг.

dikiy

WTF!?

да я сам фшоке. Собирается-то как обычно. Долго, но пох. А потом ВНЕЗАПНО ld и параметров на пол-экрана. И всё. Наглухо вязнет в свопе.

Чтож, желаю успеха. Такие мелочи как куча електричества и свободного времени видимо у вас есть.

jcd

разве причина не может быть общей?

причины 12309 разнообразны и непонятны. А тут причина проста и понятна - собирается фф из Over9000 модулей, которые все должны быть в памяти. Вот в шиндошс уже 3х гигов не хватает, а там у них на 32х битах больше и нет. Вообще непонятно, как 32х битный фф собирать...

Такие мелочи как куча електричества и свободного времени видимо у вас есть.

Сожалею тем, у кого электричества так мало, что есть разница между простаивающим и работающим процессором.

А вот свободное время, как раз, есть. Во многом — благодаря именно Gentoo :)

разве причина не может быть общей?

причина чего, простите? уход в свап это тормоза по определению.

Какой этот ваш линукс сложный ...

AMD Sempron(tm) Processor 2800+ 1.6 GHz

640 Mb RAM

УМВР, ЧЯДНТ?

Использовать source-based на таких машинах это чистой воды мазохизм, так что не понимаю твоих жалоб, что хотел то и получил :)

А можно узнать , сферический в вакууме самоскомпиленный фаерфокс на самом деле быстрее? или это фантастика?

GNU-Ubuntu1204LTS

А можно узнать , сферический в вакууме самоскомпиленный фаерфокс на самом деле быстрее? или это фантастика?

вроде тоже самое. Хотя наверное можно попробовать всякие опции. Вообще именно ФФ собирать ИМХО нет смысла, бинарники с сайта или от Патрега ничем не хуже. А вот IceCat просто не существует, кроме как в сырцах. Ну я про посл. версию. Сейчас вот попробую собрать десятую.

Во всём виноват Питон

Он ещё и слабонервный =D Даже на меня нервов не хватило: во френдах у него.

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

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

Другой немножко — firefox 10.0.2. Но это не суть важно.

На FreeBSD компиляция хоть в текстовой консоли, хоть в графическом терминале практически НИКАК не сказывается на отзывчивости интерфейса пользователя и на работе запущенных программ.

Кроме того, компиляция мозилловских приложений на FreeBSD возможна с использованием системного LLVM/Clang 3.0 вместо традиционного GCC. Это заметно сказывается на скорости сборки приложения (примерно на 25-30% быстрее).

Как называется шрифт в терминале?

StrongDollar

Во всём виноват Питон

чё?

iZEN

На FreeBSD компиляция хоть в текстовой консоли, хоть в графическом терминале практически НИКАК не сказывается на отзывчивости интерфейса пользователя и на работе запущенных программ.

дык в Linux тоже не сказывается. НИКАК. Но если памяти не хватает, FreeBSD всё равно работает? Вы в сказки верите?

iZEN

Это заметно сказывается на скорости сборки приложения (примерно на 25-30% быстрее).

да плевать на скорость сборки. Она тут всех устраивает. Проблема в том, что ld линкует 100500 разных файлов. Во фряхе это как-то иначе работает?

Компиляешь, вестимо :}

1) Это не 12309
2) Я компилил лису на 2Гб рамы без проблем
3) ССЗБ

Да запарили уже баги путать. 12309 - это iowait, а не оверсвоппинг.

У меня 8 гигов оперативной памяти на нетпуке.

да плевать на скорость сборки. Она тут всех устраивает.

ТС не устраивает же. И меня, кстати, тоже скорость GCC не устраивает (хоть в последних версиях GCC 4.6.x её и подняли).

Проблема в том, что ld линкует 100500 разных файлов. Во фряхе это как-то иначе работает?

В LLVM собственный линковщик, отличные от GCC ld.

вся прелесть заключается в жутком 12309 при работе ld

Еще один, путающий 12309 со своппингом

iZEN

ТС не устраивает же.

дык ему памяти не хватило. Что тут удивительного? У меня в init 1 на 512и не линковалось, а он наверняка в иксах да какой-нит г-но юнити делает. На gcc вполне хватает, там где-то метров 100..120 на файл надо. А вот ld...

iZEN

В LLVM собственный линковщик, отличные от GCC ld.

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

дык в Linux тоже не сказывается. НИКАК.

А но и видно. :))

Но если памяти не хватает, FreeBSD всё равно работает? Вы в сказки верите?

Во FreeBSD более оптимально работает с виртуальной памятью и со SWAP, в частности. Например, во FreeBSD по возможности используется вся доступная оперативная память, и только когда она заполнена на 95-99%, тогда начинается свопинг.

В Linux ситуация работы со SWAP несколько другая — больше смахивает на ту стратегию, которая используется в Windows XP: SWAP «заступается» уже при 50-60% использовании ОЗУ и надо рулить параметром swapiness, либо отключать SWAP вообще, чтобы избавиться от излишней дисковой активности.

Quasar

12309 - это iowait

не. Это НЁХ. Был-бы это iowait давно-бы исправили. А сколько лет уже висит?

хотя конечно к сборке ФФ 12309 не имеет никакого отношения.

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

Так собрал операционную систему и 99% установленных пакетов программ с помощью системного LLVM/Clang 3.0, Firefox 10.0.2 в том числе.

Вот только у меня не 1 ГБ ОЗУ (видимо, для эксперимента нужно собрать старенький ПК с Athlon XP и 1 ГБ DDR-333, но что-то не хочется с этим барахлом возиться, чтобы подтвердить идею).

iZEN

А но и видно. :))

что «видно»? Я прямо сейчас icecat 10 собираю. Если-бы не шум вентилятора, я-бы об этом забыл. Ну и коньки 70% CPU показывают.

iZEN

Во FreeBSD более оптимально работает с виртуальной памятью и со SWAP, в частности. Например, во FreeBSD по возможности используется вся доступная оперативная память, и только когда она заполнена на 95-99%, тогда начинается свопинг.

и что тут хорошего? В Linux свопится только мёртвая, неиспользуемая память. Иные сервера у меня по полгода работают, и свопа там 0. А на десктопе - да. Утечки, знаете-ли...

iZEN

В Linux ситуация работы со SWAP несколько другая — больше смахивает на ту стратегию, которая используется в Windows XP: SWAP «заступается» уже при 50-60% использовании ОЗУ

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

iZEN

либо отключать SWAP вообще, чтобы избавиться от излишней дисковой активности.

ну я не знаю. Может это какие-то убунтопроблемы? У меня такого не было никогда...