Это нехватка оперативной памяти

Как понять, что не хватает? top показывает неадекватные значения?

Нужен файл лога, портеж после ошибки выдает путь к нему

У тебя кончается место в каталоге сборки, он в tmpfs и по умолчанию равен половине оперативки

О! Это реальная помощь. Погуглил. Получается, если записать в fstab что-то вроде

tmpfs /tmp tmpfs rw,nosuid,noatime,nodev,size=24G,mode=1777 0 0

то можно будет запускать компилирование на бОльшем количестве ядер?

Полный лог сборки нужен - он находится в /var/tmp/portage/<category>/<package>/temp/build.log

Читай https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs

В частности, обрати внимание на https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time

Только не /tmp, а /var/tmp(или хотя бы /var/tmp/portage)

сколько бы не было памяти, с tmpfs некоторые пакеты валятся. У меня например принципиально не хотел ставиться mono пока не убрал tmpfs, хотя было 24 гига рамы и ещё своп

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

32 Гб RAM за глаза при -j16 даже для монстров типа llvm, clang, хромиума и seamonkey.

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

«Компилятор падает» если проблемы с процессором и RAM, как вариант перегрев, если ОЗУ достаточно.

По личному опыту сборка падала в сегфолт из-за того, что сгорел вентилятор на башне. Т.е. проблема проявлялась исключительно, когда собиралось что-то монструозно длительное типа clang или spidermonkey со 100% загрузкой процессора, а так всё работало без проблем.

По-моему с nvme ssd вообще нет смысла пихать сборку в оперативку, можно чисто на ssd собирать

Все равно в оперативке немного быстрее, плюс не расходуется ресурс ssd

Не один год собираю пакеты в 4гб tmpfs. Нничего не валится.

и еще иллюстрация, скрины:
https://imgur.com/a/aM27KQd
6 гиг памяти.
В tmpfs лежит файл размером 780 ГБ.
Как вам такое?

Zram и сборка в памяти. (комментарий)

Может этот коммент заинтересует к прочтению всего треда.

Скорее всего какая-то несогласованность в управлении вычислительными потоками среди высокопроизводительных и энергоэффективных ядер процессора i7-12700KF. Дело в ядре Linux.

Нет, проблема не в этом. Отключение энергоэффективных ядер в BIOS не решает проблему.

Никакие манипуляции с размером tmpfs или его размещением на SSD также не решают проблему.

Перегрева процессора нет и в других операционных системах самые жесткие стресс-тесты не вызывают ошибок.

Вот что в build.log:

https://drive.google.com/file/d/1eWYQptu7StxhkfCtpHMV7rEX7yNkPHTV/view?usp=sharing

Вот что в build.log:

«Предварительный просмотр недоступен»

Естественно, недоступен. google не умеет читать логи. Скачивается на жёсткий диск и открывается.

А оно кому надо вам или нам? Чего на пастебин не залить?

https://pastebin.pl/view/47d58917

Надо посмотреть ещё dmesg на предмет oom-kill, очень похоже, что не хватает RAM для сборки.

В выводе dmesg нет упоминаний о oom-kill

Ну вот тут делятся опытом, что 32 гига при -j16 недостаточно - https://forums.gentoo.org/viewtopic-p-8605911.html#8605911

Как не исключена ещё и ошибка gcc. На гентушном форуме тема далеко не одна про qtwebengine.

Upd. В funtoo в ебилде ограничения заложены по количеству физических ядер для qtwebengine.

С чем ещё проблемы сборки?

qtwebengine в 16 потоков на 32 Гб?

qtwebengine и seamonkey очень память выжирают быстро при многопоточной сборке. Специально для них можно ограничения в количество потоков выставить, ограничив хотя бы «8» в качестве теста: https://wiki.gentoo.org/wiki//etc/portage/package.env

То есть уменьшай для этих пакетов кол-во потоков и отпишись как успехи.

Пересборка qt5-webengine-5.15.2 на FreeBSD 13.2-STABLE:

last pid: 49171;  load averages: 24,27, 23,79, 18,51    up 0+00:22:19  21:20:13
108 processes: 26 running, 82 sleeping
CPU:  0,2% user, 96,5% nice,  3,3% system,  0,0% interrupt,  0,0% idle
Mem: 14G Active, 1654M Inact, 61M Laundry, 2747M Wired, 13G Free
ARC: 1488M Total, 723M MFU, 736M MRU, 280K Anon, 6413K Header, 23M Other
     1346M Compressed, 2098M Uncompressed, 1,56:1 Ratio
Swap: 18G Total, 18G Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
49149 root          1 101   10   610M   499M CPU13   13   0:09 100,35% clang-15
49122 root          1 106   10   914M   749M CPU4     4   0:15 100,33% clang-15
49140 root          1 104   10   799M   639M CPU12   12   0:12 100,28% clang-15
49136 root          1 105   10   799M   667M CPU21   21   0:13 100,24% clang-15
49137 root          1 104   10   799M   646M CPU8     8   0:13 100,23% clang-15
49107 root          1 108   10  1083M   891M CPU7     7   0:18 100,23% clang-15
49097 root          1 109   10  1084M   955M CPU19   19   0:20 100,12% clang-15
49114 root          1 108   10  1083M   854M CPU1     1   0:17 100,10% clang-15
49131 root          1 105   10   790M   686M CPU6     6   0:14 100,06% clang-15
49156 root          1  97   10   467M   386M CPU5     5   0:07 100,06% clang-15
49138 root          1 104   10   799M   642M CPU23   23   0:13 100,00% clang-15
49155 root          1  98   10   525M   416M CPU15   15   0:07  99,97% clang-15
49105 root          1 108   10  1084M   921M CPU16   16   0:19  99,89% clang-15
49132 root          1 105   10   800M   680M RUN     18   0:14  99,75% clang-15
49153 root          1  99   10   525M   425M CPU17   17   0:08  99,55% clang-15
49150 root          1 100   10   609M   476M CPU14   14   0:09  99,47% clang-15
49161 root          1  90   10   296M   229M CPU9     9   0:03  98,78% clang-15
49165 root          1  87   10   234M   163M CPU11   11   0:01  84,68% clang-15
49166 root          1  86   10   208M   140M CPU10   10   0:01  61,37% clang-15
23499 root          1  52   10   341M   263M select  19   0:29   2,17% ninja
 1261 igor          4  21    0   142M    65M RUN     18   0:18   2,12% xfce4-te
 1167 root          3  20    0    24G    68M select  17   0:36   1,67% Xorg
 5348 igor        107  20    0  3323M   592M select  21   1:55   0,59% thunderb
49026 igor         29  20    0   239M    84M select  21   0:00   0,25% mate-sys
23194 root          1  30   10    15M  3532K select  16   0:04   0,20% make
23497 root          1  30   10    13M  3268K select   3   0:04   0,20% make
23191 root          1  30   10    13M  3028K select  16   0:04   0,18% make
23425 root          1  30   10    13M  3224K select   3   0:03   0,15% make
 1215 igor          4  20    0   118M    56M select   4   0:00   0,13% xfwm4
49102 igor          1  20    0    14M  4040K CPU18   18   0:00   0,12% top
  815 root          1  20    0    13M  2556K select  21   0:02   0,09% moused
21483 igor         19  20    0   874M   468M select   0   0:14   0,06% chrome
 1249 igor          1  20    0    15M  4708K select   3   0:01   0,06% xscreens
48970 igor         18  20    0  1114G   246M uwait   21   0:01   0,05% chrome
21486 igor          7  33    0   352M   144M uwait   15   0:01   0,04% chrome
 1245 igor          5  20    0   144M    59M select   4   0:00   0,03% wrapper-
 1244 igor          4  20    0   176M    46M select  22   0:01   0,03% wrapper-
48975 igor         33  20    0  1114G   261M uwait   19   0:02   0,02% chrome
49027 igor          1  20    0    17M  5480K piperd   7   0:00   0,01% libgtop_
 1208 igor          1  20    0    14M  4472K select  15   0:00   0,01% dbus-dae
 1135 root          1  20    0    28M  6356K select  20   0:00   0,01% mountd
 1223 igor          4  20    0   132M    58M select   7   0:01   0,01% xfce4-pa
 1222 igor          4  20    0    96M    42M select  10   0:00   0,01% xfsettin
 1246 igor          4  20    0    96M    42M select  13   0:00   0,01% wrapper-
 1200 igor          4  20    0    90M    34M select  12   0:00   0,01% xfce4-se
 1224 igor          4  20    0    95M    37M select  15   0:00   0,01% thunar

Давно уже убедился, что

• на 2-х потоках всегда гарантированно собирается пакет любого размера.

• на 4-х потоках всегда собирается мелкие пакеты и обычно собираются тяжёлые пакеты.

• на 8-ми потоках сборка тяжёлых пакетов, как правило, падает.

Особенность в том, что тот же qtwebengine может упасть, скажем, на [3150], а может и на [23500]

И что? По своему опыту могу сказать, что в системе с 4 гигабайтами больше 2 потоков для него лучше не ставить, а на 8 гб больше 4 - иначе начнёт уходить в swap, что сильно замедлит. К тому же потребление памяти может зависеть от того, включена ли опция jumbo-build, вот она, возможно увеличивает её потребление, зато ускоряет сборку.

Ну так настрой сборку тяжёлых пакетов, которые падают тогда на 6 ядер, как описано по ссылке выше.

Тот же spidermonkey жрёт при сборке много, но если не полезет в своп, то собирается быстро.

А сколько вообще свободного места на «разделе», где происходит сборка?

А можно поинтересоваться, зачем нужен spidermonkey, почему он так важен?

уменьшай для этих пакетов кол-во потоков

Или можно в MAKEOPTS ограничить --load-average, что имхо более универсально.

Много. Очень много. Искусственное ограничение по потокам сборки - это костыль. Причина не в нехватке памяти. Что-то здесь разработчики не дотянули. Пакеты должны безошибочно компилироваться хоть в 2 потока, хоть в 22. Не хватает памяти - есть своп на 40 гигов. Так, как это происходит в других дистрибутивах. Понятно, что есть оптимальное количество потоков, при котором будет максимальная скорость сборки. Но, повторяю, и при 22-х потоках не должно быть ошибок.

А точно проблема не в настройках?

Может для начала system пересобрать с флагами cpuids2cpuflags, какой у тебя make.conf?

Пакеты собираются в /var/tmp/portage, я его в tmpfs смонтировал и 22Gb хватает на все пакеты, включая раст, огнелис, либреоффис… В 8 потоков…

Что в логах? dmesg, лог сборки, …

Может у тебя тупо проц по TDP отрубает все…

Больше не нужен, вместо него в ряде пакетов можно теперь duktape использовать.

Забудь про своп при сборке. Так то в свое лезть должно, но лучше этого не допускать.

Попробуй баг завести на qtwebengine.

Может для начала system пересобрать с флагами cpuids2cpuflags

С этим всё нормально, сделано в соответствии с gentoo handbook

Может у тебя тупо проц по TDP отрубает все…

Нет

make build failed for www/qt5-webengine

— не собирается ни Clang-15, ни Clang-14.

16 потоков - это чересчур для 32Гигов.

Компилятору надо самый минимум 2Гб на поток, а то и больше, а ещё и система должна работать, ей тоже память нужна. Надеяться на своп или zram - это несерьёзно.

Я себе проц (кол-во потоков) выбирал под количество памяти. Те же 32Гб, но проц i5-12400. Максимум j10.

Вот такой расклад: 10 потоков - 20 Гб компилеру, 10 Гб - под tmpfs для /var/tmp/portage. Оставшиеся 2 потока проца и 2 Гига памяти - для системы, чтобы можно было работать, пока компиляет.

Попробуй выставь j10 и tmpfs 10 гиг. Должно хватить. Я webengine не собирал, но пакеты типа gcc и llvm спокойно собираются. Если tmpfs потребуется больше чем 10 гиг - в ебилде это контролируется (количество свободного места), получишь предупреждение перед началом сборки

А можно поинтересоваться, зачем нужен spidermonkey, почему он так важен?

Полкит.

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

В конце-концов остановился на таком варианте решения.

1. Настройки tmpfs - по умолчанию

2. MAKEOPTS=‘-j12’ (12 физических ядер в процессоре)

3. Если компилятор падает, то возобновляю процесс с места падения командой

ebuild /var/db/repos/gentoo/net-libs/webkit-gtk/webkit-gtk-2.6.5.ebuild merge

При любом раскладе это в несколько раз быстрее, чем компилировать в 2 потока.

Имеет смысл чтобы экономить запись в ssd на мелких пакетах

Ну, и как к примеру llvm со всеми таргетами (привет, растопараша) живёт в 4гб tmpfs?

Никак. Он просто у меня не живет.

к примеру llvm со всеми таргетами

А зачем тебе сразу все?

привет, растопараша

dev-lang/rust-bin

Все сразу нужны были мейнтейнерам gentoo, более года назад при сборке llvm они зафорсили все таргеты из-за откровенного говнокода в rust и в api llvm, что здесь вылилось в кучу срачей. У меня конечно же отключено это дело, но пришлось повозиться

Установка rust-bin не спасёт тебя от зафоршенных llvm таргетов

rust-bin вообще от llvm не зависит, он свой бинарник с собой тащит

Однако куча вещей, никак не связанных с rust зависит

Ещё настроить своп, zswap, и конкретно для tmpfs под сборку надо накрутить побольше inod'ов, значения по умолчанию может не хватить и будет выглядеть как будо кончилось место.