Created attachment 21180 [details] файл сборки на aarch64 Привет! Сборочница на aarch64 продолжает творить чудеса на ровном месте. Теперь на очереди OpenUSD: https://packages.altlinux.org/tasks/415722 subtask name aarch64 i586 x86_64 #200 OpenUSD 1:24:09 - 14:49 .. Если посмотреть логи сборки (во вложении) то там вылазит следующее: x86_64: [00:02:37] [3902/4865] /usr/bin/c++ ... -c /usr/src/RPM/BUILD/OpenUSD-25.11/pxr/usdImaging/usdImaging/extentsHintSchema.cpp [00:02:37] [3903/4865] /usr/bin/c++ ...-c /usr/src/RPM/BUILD/OpenUSD-25.11/pxr/usdImaging/usdImaging/niPrototypePruningSceneIndex.cpp aarch64: [00:04:16] [3492/4456] /usr/bin/c++ ... -c /usr/src/RPM/BUILD/OpenUSD-25.11/pxr/usdImaging/usdImaging/modelSchema.cpp [00:05:07] [3493/4456] /usr/bin/c++ ... -c /usr/src/RPM/BUILD/OpenUSD-25.11/pxr/usdImaging/usdImaging/modelSchema.cpp т.е. разница между сборками почти минута на aarch64. Целая минута на сборку одного файла это как-то много. Железа aarch64 у меня нет, поэтому как это проверить не знаю, но раз такие тайминги вылезают при сборке простого кода на c++, я не удивляюсь что не собирается что-то более тяжелое.
Created attachment 21181 [details] файл сборки на x86_64
Попробуйте ограничить nproc до, например, 40 (cmake -j 40).
(In reply to Andrew Vasilyev from comment #2) > Попробуйте ограничить nproc до, например, 40 (cmake -j 40). т.е. постучать по колесам и вытряхнуть пепельницу? если посмотреть историю сборки OpenUSD, то эта проблема плавающая, когда пакет собирается 1.5 часа, а когда и 10 минут. https://git.altlinux.org/tasks/archive/done/_395/404518/build/1100/aarch64/log тут пакет собрался за 12 минут. хотелось бы услышать ответ по существу.
(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #3) > (In reply to Andrew Vasilyev from comment #2) > т.е. постучать по колесам и вытряхнуть пепельницу? если посмотреть историю Нет, это именно попытка решения проблемы. Например: 4:36:08elapsed 1633%CPU (0avgtext+0avgdata 14153488maxresident)k -j96 2:01:05elapsed 2827%CPU (0avgtext+0avgdata 15756004maxresident)k -j42 Сборка одного и того же пакета с разным -j. Под aarch64 разница более 4-х раз. Связано с тем, что при большом nproc (а на новых серверах это >100) начинается жёсткий swap из-за нехватки памяти, а в Линуксе он исторически кривой и тормозной :(
(In reply to Andrew Vasilyev from comment #4) > (Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #3) > > (In reply to Andrew Vasilyev from comment #2) > > т.е. постучать по колесам и вытряхнуть пепельницу? если посмотреть историю > > Нет, это именно попытка решения проблемы. Например: > > 4:36:08elapsed 1633%CPU (0avgtext+0avgdata 14153488maxresident)k -j96 > 2:01:05elapsed 2827%CPU (0avgtext+0avgdata 15756004maxresident)k -j42 > > Сборка одного и того же пакета с разным -j. Под aarch64 разница более 4-х > раз. > > Связано с тем, что при большом nproc (а на новых серверах это >100) > начинается жёсткий swap из-за нехватки памяти, а в Линуксе он исторически > кривой и тормозной :( это не решение проблемы а костыль - если известно, что сборочнице изменилось кол-во CPU и их использование приводит к нехватке памяти при стандартных настройках, то либо это кол-во нужно уменьшить, либо память нужно увеличить, зачем плодить всю эту чехарду с NPROC внутри .spec _каждого_ приложения?
Было уже когда-то обсуждение: https://bugzilla.altlinux.org/show_bug.cgi?id=35112 Тогда 1GB на процесс казалось много. В rpm-build-intro есть макрос %_tune_parallel_build_by_procsize Но всё это да, костыли. Только сборочницу никто чинить не будет (с новым llvm под aarch64 опять за 6 часов сборка вылетает) :(
