* [devel] Fwd: [#254123] TESTED del=clickhouse
@ 2020-06-27 7:21 ` Anton Farygin
2020-06-27 9:21 ` Andrey Savchenko
2020-06-27 10:03 ` Dmitry V. Levin
0 siblings, 2 replies; 16+ messages in thread
From: Anton Farygin @ 2020-06-27 7:21 UTC (permalink / raw)
To: ALT Linux Team development discussions
Я прошу ещё раз обратить внимание разработчиков beehive, что такое
поведение неприемлемо.
Данный пакет отлично собирается как в сборочнице так и локально. Удалять
работающие пакеты из репозитория по причине того, что с ними не
спавляется beehive крайне некорректно.
-------- Forwarded Message --------
Subject: [#254123] TESTED del=clickhouse
Date: Sat, 27 Jun 2020 05:52:38 +0000
From: Girar Builder awaiter robot <girar-builder@altlinux.org>
Reply-To: beekeeper@altlinux.org
To: ALT beekeper <beekeeper@altlinux.org>
CC: Anton Farygin <rider@altlinux.org>,
girar-builder-sisyphus@altlinux.org, sisyphus-incominger@lists.altlinux.org
http://git.altlinux.org/tasks/254123/logs/events.1.1.log
2020-Jun-27 05:38:37 :: test-only task #254123 for sisyphus started by
beekeeper:
2020-Jun-27 05:38:37 :: message: test removal of 19+ weeks ftbfs package
#100 delete clickhouse
2020-Jun-27 05:38:38 :: build check OK
2020-Jun-27 05:38:38 :: noarch check OK
2020-Jun-27 05:38:41 :: plan: src +0 -1 =17673, aarch64 +0 -6 =28757,
x86_64 +0 -6 =30760
2020-Jun-27 05:38:41 :: version check OK
2020-Jun-27 05:43:16 :: generated apt indices
2020-Jun-27 05:43:16 :: created next repo
2020-Jun-27 05:46:17 :: dependencies check OK
2020-Jun-27 05:48:45 :: [x86_64 aarch64] ELF symbols check OK
2020-Jun-27 05:49:50 :: [x86_64-i586] generated apt indices
2020-Jun-27 05:49:50 :: [x86_64-i586] created next repo
2020-Jun-27 05:50:32 :: [x86_64-i586] dependencies check OK
2020-Jun-27 05:50:32 :: gears inheritance check OK
2020-Jun-27 05:50:32 :: srpm inheritance check OK
girar-check-perms: access to clickhouse ALLOWED for beekeeper: project
leader welcomes random builders
check-subtask-perms: #100: clickhouse: allowed for beekeeper
2020-Jun-27 05:50:33 :: acl check OK
2020-Jun-27 05:51:36 :: created contents_index files
2020-Jun-27 05:52:31 :: created hash files: aarch64 src x86_64
2020-Jun-27 05:52:37 :: task #254123 for sisyphus TESTED
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 7:21 ` [devel] Fwd: [#254123] TESTED del=clickhouse Anton Farygin
@ 2020-06-27 9:21 ` Andrey Savchenko
2020-06-27 9:44 ` Anton Farygin
2020-06-27 10:03 ` Dmitry V. Levin
1 sibling, 1 reply; 16+ messages in thread
From: Andrey Savchenko @ 2020-06-27 9:21 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- Attachment #1: Type: text/plain, Size: 3752 bytes --]
On Sat, 27 Jun 2020 10:21:47 +0300 Anton Farygin wrote:
> Я прошу ещё раз обратить внимание разработчиков beehive, что такое
> поведение неприемлемо.
>
> Данный пакет отлично собирается как в сборочнице так и локально. Удалять
> работающие пакеты из репозитория по причине того, что с ними не
> спавляется beehive крайне некорректно.
Я понимаю ситуацию следующим образом: управляющие beehive считают,
что если не пересобралось — значит ошибка в пакете. В приципе,
здесь они, вероятнее всего, правы: на высоконагруженных системах
действительно нередко выявляются баги, не проявляющиеся при меньших
нагрузках.
Где они не правы: не предоставляется информация необходимая для
отладки, несмотря на неоднократные запросы. В подавляющем
большинстве проектов такие баги закрываются как NEEDINFO /
WORKSFORME. Проблема в том, что управляющие beehive являются также
управляющими сборочницы и на правах сильного ставят позицию
следующим образом: исправляйте как хотите, но если не исправите,
ваш пакет будет удалён.
> -------- Forwarded Message --------
> Subject: [#254123] TESTED del=clickhouse
> Date: Sat, 27 Jun 2020 05:52:38 +0000
> From: Girar Builder awaiter robot <girar-builder@altlinux.org>
> Reply-To: beekeeper@altlinux.org
> To: ALT beekeper <beekeeper@altlinux.org>
> CC: Anton Farygin <rider@altlinux.org>,
> girar-builder-sisyphus@altlinux.org, sisyphus-incominger@lists.altlinux.org
>
>
>
> http://git.altlinux.org/tasks/254123/logs/events.1.1.log
>
> 2020-Jun-27 05:38:37 :: test-only task #254123 for sisyphus started by
> beekeeper:
> 2020-Jun-27 05:38:37 :: message: test removal of 19+ weeks ftbfs package
> #100 delete clickhouse
> 2020-Jun-27 05:38:38 :: build check OK
> 2020-Jun-27 05:38:38 :: noarch check OK
> 2020-Jun-27 05:38:41 :: plan: src +0 -1 =17673, aarch64 +0 -6 =28757,
> x86_64 +0 -6 =30760
> 2020-Jun-27 05:38:41 :: version check OK
> 2020-Jun-27 05:43:16 :: generated apt indices
> 2020-Jun-27 05:43:16 :: created next repo
> 2020-Jun-27 05:46:17 :: dependencies check OK
> 2020-Jun-27 05:48:45 :: [x86_64 aarch64] ELF symbols check OK
> 2020-Jun-27 05:49:50 :: [x86_64-i586] generated apt indices
> 2020-Jun-27 05:49:50 :: [x86_64-i586] created next repo
> 2020-Jun-27 05:50:32 :: [x86_64-i586] dependencies check OK
> 2020-Jun-27 05:50:32 :: gears inheritance check OK
> 2020-Jun-27 05:50:32 :: srpm inheritance check OK
> girar-check-perms: access to clickhouse ALLOWED for beekeeper: project
> leader welcomes random builders
> check-subtask-perms: #100: clickhouse: allowed for beekeeper
> 2020-Jun-27 05:50:33 :: acl check OK
> 2020-Jun-27 05:51:36 :: created contents_index files
> 2020-Jun-27 05:52:31 :: created hash files: aarch64 src x86_64
> 2020-Jun-27 05:52:37 :: task #254123 for sisyphus TESTED
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 9:21 ` Andrey Savchenko
@ 2020-06-27 9:44 ` Anton Farygin
2020-06-27 10:23 ` Dmitry V. Levin
0 siblings, 1 reply; 16+ messages in thread
From: Anton Farygin @ 2020-06-27 9:44 UTC (permalink / raw)
To: devel
On 27.06.2020 12:21, Andrey Savchenko wrote:
> On Sat, 27 Jun 2020 10:21:47 +0300 Anton Farygin wrote:
>> Я прошу ещё раз обратить внимание разработчиков beehive, что такое
>> поведение неприемлемо.
>>
>> Данный пакет отлично собирается как в сборочнице так и локально. Удалять
>> работающие пакеты из репозитория по причине того, что с ними не
>> спавляется beehive крайне некорректно.
> Я понимаю ситуацию следующим образом: управляющие beehive считают,
> что если не пересобралось — значит ошибка в пакете. В приципе,
> здесь они, вероятнее всего, правы: на высоконагруженных системах
> действительно нередко выявляются баги, не проявляющиеся при меньших
> нагрузках.
>
> Где они не правы: не предоставляется информация необходимая для
> отладки, несмотря на неоднократные запросы. В подавляющем
> большинстве проектов такие баги закрываются как NEEDINFO /
> WORKSFORME. Проблема в том, что управляющие beehive являются также
> управляющими сборочницы и на правах сильного ставят позицию
> следующим образом: исправляйте как хотите, но если не исправите,
> ваш пакет будет удалён.
>
/usr/bin/c++ -pipe -frecord-gcc-switches -Wall -g -O2 -fsized-deallocation -pipe -msse4.1 -msse4.2 -mpopcnt -fno-omit-frame-pointer -Wall -Wnon-virtual-dtor -Wno-array-bounds -Wextra -Wshadow -O2 -DNDEBUG -fuse-ld=gold -rdynamic -Wl,--no-undefined -rdynamic CMakeFiles/select_query.dir/select_query.cpp.o -o select_query ../../../libclickhouse_new_delete.a ../../Storages/System/libclickhouse_storages_system.a ../../../libdbms.a ../../../libclickhouse_common_io.a ../../Common/Config/libclickhouse_common_config.a ../../Dictionaries/Embedded/libclickhouse_dictionaries_embedded.a /usr/lib64/liblz4.so ../../../../libs/libmysqlxx/libmysqlxx.a /usr/lib64/libmysqlclient.so -ldl ../../../../contrib/libbtrie/libbtrie.a /usr/lib64/libboost_filesystem.a /usr/lib64/libzstd.so /usr/lib64/libPocoDataODBC.so /usr/lib64/libodbc.so /usr/lib64/libPocoMongoDB.so /usr/lib64/libicui18n.so /usr/lib64/libicuuc.so /usr/lib64/libicudata.so /usr/lib64/libcapnpc.a /usr/lib64/libcapnp.a /usr/lib64/libkj.a /usr/lib64/libprotobuf.so ../../Common/ZooKeeper/libclickhouse_common_zookeeper.a ../../Parsers/libclickhouse_parsers.a ../../../libclickhouse_common_io.a ../../../../libs/libcommon/libcommon.a /usr/lib64/libcctz.so ../../../../libs/libmemcpy/libmemcpy.a ../../Common/StringUtils/libstring_utils.a ../../../../libs/libwidechar_width/libwidechar_width.a /usr/lib64/libdouble-conversion.so /usr/lib64/libPocoNet.so /usr/lib64/libPocoFoundation.so /usr/lib64/libPocoUtil.so /usr/lib64/libre2.so /usr/lib64/libboost_program_options.a /usr/lib64/libboost_system.a /usr/lib64/libPocoXML.so ../../../../contrib/cityhash102/libcityhash.a /usr/lib64/libz.so ../../../../libs/libcommon/libapple_rt.a ../../../../contrib/croaring/libroaring.a ../../../../contrib/libcpuid/libcpuid.a -Wl,--start-group -l:libstdc++.a -l:libstdc++fs.a -lgcc_eh -Wl,--end-group /usr/lib64/libPocoData.so /usr/lib64/libPocoNetSSL.so /usr/lib64/libssl.so /usr/lib64/libPocoCrypto.so /usr/lib64/libcrypto.so /usr/lib64/libbrotlidec.so /usr/lib64/libbrotlienc.so /usr/lib64/libbrotlicommon.so -nodefaultlibs -lgcc -lc -lm -lrt -lpthread -ldl
collect2: fatal error: ld terminated with signal 9 [Killed]
compilation terminated.
И как мне это прикажете чинить ? уменьшить количество потоков в параллельной сборке - тогда локально будет плохо. Да и опять же - увеличьте количество памяти.
Есть ли возможность как-то сдетектить, что сборка выполняется в окружении beehive ?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 7:21 ` [devel] Fwd: [#254123] TESTED del=clickhouse Anton Farygin
2020-06-27 9:21 ` Andrey Savchenko
@ 2020-06-27 10:03 ` Dmitry V. Levin
2020-06-27 10:16 ` Andrey Savchenko
1 sibling, 1 reply; 16+ messages in thread
From: Dmitry V. Levin @ 2020-06-27 10:03 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Sat, Jun 27, 2020 at 10:21:47AM +0300, Anton Farygin wrote:
> Я прошу ещё раз обратить внимание разработчиков beehive, что такое
> поведение неприемлемо.
>
> Данный пакет отлично собирается как в сборочнице так и локально. Удалять
> работающие пакеты из репозитория по причине того, что с ними не
> спавляется beehive крайне некорректно.
beehive и girar - это одна и та же сборочница.
Логи тестовой пересборки общедоступны.
Как именно не пересобирается пакет clickhouse, видно невооружённым глазом:
$ lftp -c 'cat http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/latest/error/clickhouse-19.17.9.60-alt1' |grep -F Killed
collect2: fatal error: ld terminated with signal 9 [Killed]
x86_64-alt-linux-g++: fatal error: Killed signal terminated program cc1plus
x86_64-alt-linux-g++: fatal error: Killed signal terminated program cc1plus
Почему именно Killed, я уже рассказывал, могу повторить:
Jun 27 01:31:01 kernel: cc1plus invoked oom-killer: gfp_mask=0x500cc2(GFP_HIGHUSER|__GFP_ACCOUNT), order=0, oom_score_adj=0
Jun 27 01:31:01 kernel: CPU: 25 PID: 522715 Comm: cc1plus Not tainted 5.4.47-std-def-alt2 #1
Jun 27 01:31:01 kernel: Call Trace:
Jun 27 01:31:01 kernel: dump_stack+0x7c/0x9c
Jun 27 01:31:01 kernel: dump_header+0x4a/0x1df
Jun 27 01:31:01 kernel: oom_kill_process.cold+0xb/0x10
Jun 27 01:31:01 kernel: out_of_memory+0x198/0x430
Jun 27 01:31:01 kernel: mem_cgroup_out_of_memory+0xba/0xd0
Jun 27 01:31:01 kernel: try_charge+0x7cb/0x850
Jun 27 01:31:01 kernel: ? __switch_to_asm+0x34/0x70
Jun 27 01:31:01 kernel: ? __switch_to_asm+0x40/0x70
Jun 27 01:31:01 kernel: ? __switch_to_asm+0x34/0x70
Jun 27 01:31:01 kernel: __memcg_kmem_charge_memcg+0x3e/0xc0
Jun 27 01:31:01 kernel: __memcg_kmem_charge+0x71/0x140
Jun 27 01:31:01 kernel: __alloc_pages_nodemask+0x27b/0x330
Jun 27 01:31:01 kernel: pipe_write+0x19a/0x430
Jun 27 01:31:01 kernel: new_sync_write+0x12d/0x1d0
Jun 27 01:31:01 kernel: vfs_write+0xb6/0x1a0
Jun 27 01:31:01 kernel: ksys_write+0x5f/0xe0
Jun 27 01:31:01 kernel: do_syscall_64+0x5c/0x140
Jun 27 01:31:01 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jun 27 01:31:01 kernel: RIP: 0033:0x7f46706f3933
Jun 27 01:31:01 kernel: Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
Jun 27 01:31:01 kernel: RSP: 002b:00007ffd832d3f08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
Jun 27 01:31:01 kernel: RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007f46706f3933
Jun 27 01:31:01 kernel: RDX: 0000000000001000 RSI: 0000000002b45920 RDI: 0000000000000001
Jun 27 01:31:01 kernel: RBP: 0000000002b45920 R08: 0000000000000000 R09: 0000000001ee75f0
Jun 27 01:31:01 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001000
Jun 27 01:31:01 kernel: R13: 00007f46707c3500 R14: 0000000000001000 R15: 00007f46707c3700
Jun 27 01:31:01 kernel: memory: usage 33554432kB, limit 33554432kB, failcnt 0
Jun 27 01:31:01 kernel: memory+swap: usage 33554432kB, limit 33554432kB, failcnt 252005
Jun 27 01:31:01 kernel: kmem: usage 171172kB, limit 9007199254740988kB, failcnt 0
Jun 27 01:31:01 kernel: Memory cgroup stats for /user/wasp/wasp03:
Jun 27 01:31:01 kernel: anon 4974415872
Jun 27 01:31:01 kernel: file 29211447296
Jun 27 01:31:01 kernel: kernel_stack 700416
Jun 27 01:31:01 kernel: slab 161607680
Jun 27 01:31:01 kernel: sock 0
Jun 27 01:31:01 kernel: shmem 29209128960
Jun 27 01:31:01 kernel: file_mapped 1376415744
Jun 27 01:31:01 kernel: file_dirty 0
Jun 27 01:31:01 kernel: file_writeback 0
Jun 27 01:31:01 kernel: anon_thp 232783872
Jun 27 01:31:01 kernel: inactive_anon 23757398016
Jun 27 01:31:01 kernel: active_anon 10426613760
Jun 27 01:31:01 kernel: inactive_file 1880064
Jun 27 01:31:01 kernel: active_file 1064960
Jun 27 01:31:01 kernel: unevictable 0
Jun 27 01:31:01 kernel: slab_reclaimable 106377216
Jun 27 01:31:01 kernel: slab_unreclaimable 55230464
Jun 27 01:31:01 kernel: pgfault 9050446647
Jun 27 01:31:01 kernel: pgmajfault 0
Jun 27 01:31:01 kernel: workingset_refault 0
Jun 27 01:31:01 kernel: workingset_activate 0
Jun 27 01:31:01 kernel: workingset_nodereclaim 0
Jun 27 01:31:01 kernel: pgrefill 774449
Jun 27 01:31:01 kernel: pgscan 886250
Jun 27 01:31:01 kernel: pgsteal 886250
Jun 27 01:31:01 kernel: pgactivate 0
Jun 27 01:31:01 kernel: pgdeactivate 774449
Jun 27 01:31:01 kernel: Tasks state (memory values in pages):
Jun 27 01:31:01 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Jun 27 01:31:01 kernel: [1439889] 0 1439889 3356 1701 65536 0 0 sshd
Jun 27 01:31:01 kernel: [1440211] 530 1440211 3389 1083 65536 0 0 sshd
Jun 27 01:31:01 kernel: [4184280] 530 4184280 741 575 40960 0 0 nectar
Jun 27 01:31:01 kernel: [4184315] 530 4184315 539 193 40960 0 0 time
Jun 27 01:31:01 kernel: [4184316] 530 4184316 1421 711 49152 0 0 hsh
Jun 27 01:31:01 kernel: [4186136] 530 4186136 906 705 45056 0 0 hsh-rebuild
Jun 27 01:31:01 kernel: [ 9566] 530 9566 741 529 40960 0 0 chrootuid2.sh
Jun 27 01:31:01 kernel: [ 9568] 530 9568 605 405 45056 0 0 hasher-priv
Jun 27 01:31:01 kernel: [ 9570] 532 9570 761 568 40960 0 0 entry
Jun 27 01:31:01 kernel: [ 9575] 532 9575 539 193 45056 0 0 time
Jun 27 01:31:01 kernel: [ 9579] 532 9579 3492 1709 65536 0 0 rpmbuild
Jun 27 01:31:01 kernel: [ 10728] 532 10728 761 619 45056 0 0 sh
Jun 27 01:31:01 kernel: [ 14263] 532 14263 701 565 40960 0 0 make
Jun 27 01:31:01 kernel: [ 14341] 532 14341 992 872 45056 0 0 make
Jun 27 01:31:01 kernel: [ 304409] 532 304409 731 599 45056 0 0 make
Jun 27 01:31:01 kernel: [ 304524] 532 304524 1302 1131 53248 0 0 make
Jun 27 01:31:01 kernel: [ 379604] 532 379604 830 678 40960 0 0 make
Jun 27 01:31:01 kernel: [ 498222] 532 498222 903 197 36864 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 498223] 532 498223 278588 272249 2265088 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 498225] 532 498225 7349 6925 98304 0 0 as
Jun 27 01:31:01 kernel: [ 498488] 532 498488 903 181 40960 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 498494] 532 498494 375878 364672 3018752 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 498508] 532 498508 28363 27950 262144 0 0 as
Jun 27 01:31:01 kernel: [ 514103] 532 514103 699 548 40960 0 0 make
Jun 27 01:31:01 kernel: [ 516802] 532 516802 7284 2747 98304 0 0 cmake
Jun 27 01:31:01 kernel: [ 516824] 532 516824 903 652 45056 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 516840] 532 516840 730 197 45056 0 0 collect2
Jun 27 01:31:01 kernel: [ 516853] 532 516853 938022 542120 5844992 0 0 ld.gold
Jun 27 01:31:01 kernel: [ 522689] 532 522689 734 609 45056 0 0 make
Jun 27 01:31:01 kernel: [ 522711] 532 522711 903 197 40960 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 522715] 532 522715 115225 110914 962560 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 522728] 532 522728 4009 3607 65536 0 0 as
Jun 27 01:31:01 kernel: [ 523303] 532 523303 903 213 45056 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 523305] 532 523305 87954 82189 741376 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 523309] 532 523309 8332 7908 106496 0 0 as
Jun 27 01:31:01 kernel: [ 523901] 532 523901 903 181 40960 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 523910] 532 523910 97131 89608 798720 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 523942] 532 523942 2326 1885 53248 0 0 as
Jun 27 01:31:01 kernel: [ 524591] 532 524591 903 181 45056 0 0 x86_64-alt-linu
Jun 27 01:31:01 kernel: [ 524593] 532 524593 67278 59698 561152 0 0 cc1plus
Jun 27 01:31:01 kernel: [ 524594] 532 524594 2326 1926 61440 0 0 as
Jun 27 01:31:01 kernel: [ 525054] 532 525054 7318 2782 94208 0 0 cmake
Jun 27 01:31:01 kernel: [ 525180] 532 525180 2350 2101 57344 0 0 ranlib
Jun 27 01:31:01 kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=wasp03,mems_allowed=0-7,oom_memcg=/user/wasp/wasp03,task_memcg=/user/wasp/wasp03,task=ld.gold,pid=516853,uid=532
Jun 27 01:31:01 kernel: Memory cgroup out of memory: Killed process 516853 (ld.gold) total-vm:3752088kB, anon-rss:855460kB, file-rss:4kB, shmem-rss:1313016kB, UID:532 pgtables:5708kB oom_score_adj:0
Jun 27 01:31:01 kernel: oom_reaper: reaped process 516853 (ld.gold), now anon-rss:0kB, file-rss:0kB, shmem-rss:406168kB
Jun 27 01:31:07 kernel: cc1plus invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
Jun 27 01:31:07 kernel: CPU: 29 PID: 498494 Comm: cc1plus Not tainted 5.4.47-std-def-alt2 #1
Jun 27 01:31:07 kernel: Call Trace:
Jun 27 01:31:07 kernel: dump_stack+0x7c/0x9c
Jun 27 01:31:07 kernel: dump_header+0x4a/0x1df
Jun 27 01:31:07 kernel: oom_kill_process.cold+0xb/0x10
Jun 27 01:31:07 kernel: out_of_memory+0x198/0x430
Jun 27 01:31:07 kernel: mem_cgroup_out_of_memory+0xba/0xd0
Jun 27 01:31:07 kernel: try_charge+0x7cb/0x850
Jun 27 01:31:07 kernel: ? __alloc_pages_nodemask+0x185/0x330
Jun 27 01:31:07 kernel: mem_cgroup_try_charge+0x6c/0x190
Jun 27 01:31:07 kernel: mem_cgroup_try_charge_delay+0x1d/0x40
Jun 27 01:31:07 kernel: __handle_mm_fault+0xa31/0x1730
Jun 27 01:31:07 kernel: ? __switch_to_asm+0x34/0x70
Jun 27 01:31:07 kernel: handle_mm_fault+0xee/0x210
Jun 27 01:31:07 kernel: do_user_addr_fault+0x1d4/0x460
Jun 27 01:31:07 kernel: page_fault+0x34/0x40
Jun 27 01:31:07 kernel: RIP: 0033:0x7fa3ea49c9d1
Jun 27 01:31:07 kernel: Code: fa ff 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 0f 82 a5 00 00 00 48 83 fa 40 0f 87 08 01 00 00 c5 fe 6f 06 c5 fe 6f 4c 16 e0 <c5> fe 7f 07 c5 fe 7f 4c 17 e0 c5 f8 77 c3 90 48 39 d1 0f 82 47 a1
Jun 27 01:31:07 kernel: RSP: 002b:00007ffc56249de8 EFLAGS: 00010246
Jun 27 01:31:07 kernel: RAX: 00007fa38ba0a000 RBX: 0000000000000011 RCX: 000000000000000c
Jun 27 01:31:07 kernel: RDX: 0000000000000040 RSI: 00007fa38ba05c80 RDI: 00007fa38ba0a000
Jun 27 01:31:07 kernel: RBP: 00007fa38ba05c80 R08: 0000000000000000 R09: 0000000010000001
Jun 27 01:31:07 kernel: R10: 00007fa3a715f010 R11: 0000000000000006 R12: 00007fa38ba0a000
Jun 27 01:31:07 kernel: R13: 0000000000000040 R14: 0000000000000800 R15: 00007fa3c5fc1840
Jun 27 01:31:07 kernel: memory: usage 33554432kB, limit 33554432kB, failcnt 0
Jun 27 01:31:07 kernel: memory+swap: usage 33554432kB, limit 33554432kB, failcnt 252140
Jun 27 01:31:07 kernel: kmem: usage 163916kB, limit 9007199254740988kB, failcnt 0
Jun 27 01:31:07 kernel: Memory cgroup stats for /user/wasp/wasp03:
Jun 27 01:31:07 kernel: anon 5996515328
Jun 27 01:31:07 kernel: file 28196540416
Jun 27 01:31:07 kernel: kernel_stack 626688
Jun 27 01:31:07 kernel: slab 156876800
Jun 27 01:31:07 kernel: sock 0
Jun 27 01:31:07 kernel: shmem 28194795520
Jun 27 01:31:07 kernel: file_mapped 31764480
Jun 27 01:31:07 kernel: file_dirty 0
Jun 27 01:31:07 kernel: file_writeback 0
Jun 27 01:31:07 kernel: anon_thp 167772160
Jun 27 01:31:07 kernel: inactive_anon 22674296832
Jun 27 01:31:07 kernel: active_anon 11517210624
Jun 27 01:31:07 kernel: inactive_file 1880064
Jun 27 01:31:07 kernel: active_file 1064960
Jun 27 01:31:07 kernel: unevictable 0
Jun 27 01:31:07 kernel: slab_reclaimable 101646336
Jun 27 01:31:07 kernel: slab_unreclaimable 55230464
Jun 27 01:31:07 kernel: pgfault 9051222609
Jun 27 01:31:07 kernel: pgmajfault 0
Jun 27 01:31:07 kernel: workingset_refault 0
Jun 27 01:31:07 kernel: workingset_activate 0
Jun 27 01:31:07 kernel: workingset_nodereclaim 0
Jun 27 01:31:07 kernel: pgrefill 774449
Jun 27 01:31:07 kernel: pgscan 886250
Jun 27 01:31:07 kernel: pgsteal 886250
Jun 27 01:31:07 kernel: pgactivate 0
Jun 27 01:31:07 kernel: pgdeactivate 774449
Jun 27 01:31:07 kernel: Tasks state (memory values in pages):
Jun 27 01:31:07 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Jun 27 01:31:07 kernel: [1439889] 0 1439889 3356 1701 65536 0 0 sshd
Jun 27 01:31:07 kernel: [1440211] 530 1440211 3389 1083 65536 0 0 sshd
Jun 27 01:31:07 kernel: [4184280] 530 4184280 741 575 40960 0 0 nectar
Jun 27 01:31:07 kernel: [4184315] 530 4184315 539 193 40960 0 0 time
Jun 27 01:31:07 kernel: [4184316] 530 4184316 1421 711 49152 0 0 hsh
Jun 27 01:31:07 kernel: [4186136] 530 4186136 906 705 45056 0 0 hsh-rebuild
Jun 27 01:31:07 kernel: [ 9566] 530 9566 741 529 40960 0 0 chrootuid2.sh
Jun 27 01:31:07 kernel: [ 9568] 530 9568 605 405 45056 0 0 hasher-priv
Jun 27 01:31:07 kernel: [ 9570] 532 9570 761 568 40960 0 0 entry
Jun 27 01:31:07 kernel: [ 9575] 532 9575 539 193 45056 0 0 time
Jun 27 01:31:07 kernel: [ 9579] 532 9579 3492 1709 65536 0 0 rpmbuild
Jun 27 01:31:07 kernel: [ 10728] 532 10728 761 619 45056 0 0 sh
Jun 27 01:31:07 kernel: [ 14263] 532 14263 701 565 40960 0 0 make
Jun 27 01:31:07 kernel: [ 14341] 532 14341 992 872 45056 0 0 make
Jun 27 01:31:07 kernel: [ 304409] 532 304409 731 604 45056 0 0 make
Jun 27 01:31:07 kernel: [ 379604] 532 379604 830 689 40960 0 0 make
Jun 27 01:31:07 kernel: [ 498222] 532 498222 903 197 36864 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 498223] 532 498223 299082 292305 2433024 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 498225] 532 498225 9659 9301 118784 0 0 as
Jun 27 01:31:07 kernel: [ 498488] 532 498488 903 181 40960 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 498494] 532 498494 409399 398799 3293184 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 498508] 532 498508 41563 41150 364544 0 0 as
Jun 27 01:31:07 kernel: [ 522689] 532 522689 734 616 45056 0 0 make
Jun 27 01:31:07 kernel: [ 523901] 532 523901 903 181 40960 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 523910] 532 523910 164720 156118 1351680 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 523942] 532 523942 2326 1885 53248 0 0 as
Jun 27 01:31:07 kernel: [ 524591] 532 524591 903 181 45056 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 524593] 532 524593 149102 141968 1232896 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 524594] 532 524594 2326 1926 61440 0 0 as
Jun 27 01:31:07 kernel: [ 525260] 532 525260 903 180 40960 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 525263] 532 525263 141477 134065 1163264 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 525266] 532 525266 2326 1886 53248 0 0 as
Jun 27 01:31:07 kernel: [ 525395] 532 525395 903 213 45056 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 525402] 532 525402 135632 131981 1138688 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 525405] 532 525405 5428 5053 77824 0 0 as
Jun 27 01:31:07 kernel: [ 525507] 532 525507 903 213 40960 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 525508] 532 525508 115421 110080 958464 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 525511] 532 525511 5197 4817 81920 0 0 as
Jun 27 01:31:07 kernel: [ 526612] 532 526612 903 196 40960 0 0 x86_64-alt-linu
Jun 27 01:31:07 kernel: [ 526613] 532 526613 79555 72340 663552 0 0 cc1plus
Jun 27 01:31:07 kernel: [ 526614] 532 526614 2326 1912 53248 0 0 as
Jun 27 01:31:07 kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=wasp03,mems_allowed=0-7,oom_memcg=/user/wasp/wasp03,task_memcg=/user/wasp/wasp03,task=cc1plus,pid=498494,uid=532
Jun 27 01:31:07 kernel: Memory cgroup out of memory: Killed process 498494 (cc1plus) total-vm:1637596kB, anon-rss:1571172kB, file-rss:4kB, shmem-rss:24020kB, UID:532 pgtables:3216kB oom_score_adj:0
Jun 27 01:31:07 kernel: oom_reaper: reaped process 498494 (cc1plus), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Jun 27 01:31:20 kernel: cc1plus invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
Jun 27 01:31:20 kernel: CPU: 31 PID: 528863 Comm: cc1plus Not tainted 5.4.47-std-def-alt2 #1
Jun 27 01:31:20 kernel: Call Trace:
Jun 27 01:31:20 kernel: dump_stack+0x7c/0x9c
Jun 27 01:31:20 kernel: dump_header+0x4a/0x1df
Jun 27 01:31:20 kernel: oom_kill_process.cold+0xb/0x10
Jun 27 01:31:20 kernel: out_of_memory+0x198/0x430
Jun 27 01:31:20 kernel: mem_cgroup_out_of_memory+0xba/0xd0
Jun 27 01:31:20 kernel: try_charge+0x7cb/0x850
Jun 27 01:31:20 kernel: ? __alloc_pages_nodemask+0x185/0x330
Jun 27 01:31:20 kernel: mem_cgroup_try_charge+0x6c/0x190
Jun 27 01:31:20 kernel: mem_cgroup_try_charge_delay+0x1d/0x40
Jun 27 01:31:20 kernel: __handle_mm_fault+0xa31/0x1730
Jun 27 01:31:20 kernel: handle_mm_fault+0xee/0x210
Jun 27 01:31:20 kernel: do_user_addr_fault+0x1d4/0x460
Jun 27 01:31:20 kernel: page_fault+0x34/0x40
Jun 27 01:31:20 kernel: RIP: 0033:0x7ff4c6461eec
Jun 27 01:31:20 kernel: Code: 9d 48 81 fa 80 00 00 00 77 19 c5 fe 7f 07 c5 fe 7f 47 20 c5 fe 7f 44 17 e0 c5 fe 7f 44 17 c0 c5 f8 77 c3 48 8d 8f 80 00 00 00 <c5> fe 7f 07 48 83 e1 80 c5 fe 7f 44 17 e0 c5 fe 7f 47 20 c5 fe 7f
Jun 27 01:31:20 kernel: RSP: 002b:00007ffedc42e018 EFLAGS: 00010206
Jun 27 01:31:20 kernel: RAX: 00007ff4b58a1000 RBX: 00007ff4b589edc8 RCX: 00007ff4b58a1080
Jun 27 01:31:20 kernel: RDX: 00000000000000a8 RSI: 0000000000000000 RDI: 00007ff4b58a1000
Jun 27 01:31:20 kernel: RBP: 00007ff4b5c9a888 R08: 0000000000000000 R09: 0000000001000001
Jun 27 01:31:20 kernel: R10: 00007ff4bbe9a010 R11: 0000000000000006 R12: 00000000000000a8
Jun 27 01:31:20 kernel: R13: 0000000000000001 R14: 00007ff4b5885348 R15: 00007ff4c60f2848
Jun 27 01:31:20 kernel: memory: usage 33554432kB, limit 33554432kB, failcnt 0
Jun 27 01:31:20 kernel: memory+swap: usage 33554432kB, limit 33554432kB, failcnt 252243
Jun 27 01:31:20 kernel: kmem: usage 163488kB, limit 9007199254740988kB, failcnt 0
Jun 27 01:31:20 kernel: Memory cgroup stats for /user/wasp/wasp03:
Jun 27 01:31:20 kernel: anon 5969666048
Jun 27 01:31:20 kernel: file 28223438848
Jun 27 01:31:20 kernel: kernel_stack 552960
Jun 27 01:31:20 kernel: slab 156332032
Jun 27 01:31:20 kernel: sock 0
Jun 27 01:31:20 kernel: shmem 28222099456
Jun 27 01:31:20 kernel: file_mapped 31088640
Jun 27 01:31:20 kernel: file_dirty 0
Jun 27 01:31:20 kernel: file_writeback 0
Jun 27 01:31:20 kernel: anon_thp 142606336
Jun 27 01:31:20 kernel: inactive_anon 22696869888
Jun 27 01:31:20 kernel: active_anon 11494981632
Jun 27 01:31:20 kernel: inactive_file 1880064
Jun 27 01:31:20 kernel: active_file 1064960
Jun 27 01:31:20 kernel: unevictable 0
Jun 27 01:31:20 kernel: slab_reclaimable 101105664
Jun 27 01:31:20 kernel: slab_unreclaimable 55226368
Jun 27 01:31:20 kernel: pgfault 9052764006
Jun 27 01:31:20 kernel: pgmajfault 0
Jun 27 01:31:20 kernel: workingset_refault 0
Jun 27 01:31:20 kernel: workingset_activate 0
Jun 27 01:31:20 kernel: workingset_nodereclaim 0
Jun 27 01:31:20 kernel: pgrefill 774449
Jun 27 01:31:20 kernel: pgscan 886250
Jun 27 01:31:20 kernel: pgsteal 886250
Jun 27 01:31:20 kernel: pgactivate 0
Jun 27 01:31:20 kernel: pgdeactivate 774449
Jun 27 01:31:20 kernel: Tasks state (memory values in pages):
Jun 27 01:31:20 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Jun 27 01:31:20 kernel: [1439889] 0 1439889 3356 1701 65536 0 0 sshd
Jun 27 01:31:20 kernel: [1440211] 530 1440211 3389 1083 65536 0 0 sshd
Jun 27 01:31:20 kernel: [4184280] 530 4184280 741 575 40960 0 0 nectar
Jun 27 01:31:20 kernel: [4184315] 530 4184315 539 193 40960 0 0 time
Jun 27 01:31:20 kernel: [4184316] 530 4184316 1421 711 49152 0 0 hsh
Jun 27 01:31:20 kernel: [4186136] 530 4186136 906 705 45056 0 0 hsh-rebuild
Jun 27 01:31:20 kernel: [ 9566] 530 9566 741 529 40960 0 0 chrootuid2.sh
Jun 27 01:31:20 kernel: [ 9568] 530 9568 605 405 45056 0 0 hasher-priv
Jun 27 01:31:20 kernel: [ 9570] 532 9570 761 568 40960 0 0 entry
Jun 27 01:31:20 kernel: [ 9575] 532 9575 539 193 45056 0 0 time
Jun 27 01:31:20 kernel: [ 9579] 532 9579 3492 1709 65536 0 0 rpmbuild
Jun 27 01:31:20 kernel: [ 10728] 532 10728 761 619 45056 0 0 sh
Jun 27 01:31:20 kernel: [ 14263] 532 14263 701 565 40960 0 0 make
Jun 27 01:31:20 kernel: [ 14341] 532 14341 992 872 45056 0 0 make
Jun 27 01:31:20 kernel: [ 304409] 532 304409 731 605 45056 0 0 make
Jun 27 01:31:20 kernel: [ 379604] 532 379604 830 689 40960 0 0 make
Jun 27 01:31:20 kernel: [ 522689] 532 522689 765 659 45056 0 0 make
Jun 27 01:31:20 kernel: [ 523901] 532 523901 903 181 40960 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 523910] 532 523910 261544 254029 2121728 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 523942] 532 523942 4603 4195 73728 0 0 as
Jun 27 01:31:20 kernel: [ 524591] 532 524591 903 181 45056 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 524593] 532 524593 235176 229560 1933312 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 524594] 532 524594 4537 4104 77824 0 0 as
Jun 27 01:31:20 kernel: [ 525260] 532 525260 903 180 40960 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 525263] 532 525263 253409 245393 2060288 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 525266] 532 525266 3283 2876 61440 0 0 as
Jun 27 01:31:20 kernel: [ 526612] 532 526612 903 196 40960 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 526613] 532 526613 202009 195361 1654784 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 526614] 532 526614 21697 21316 208896 0 0 as
Jun 27 01:31:20 kernel: [ 527029] 532 527029 903 180 40960 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 527030] 532 527030 206090 201025 1703936 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 527031] 532 527031 2326 1900 57344 0 0 as
Jun 27 01:31:20 kernel: [ 527710] 532 527710 903 197 45056 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 527713] 532 527713 132171 128653 1101824 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 527714] 532 527714 11170 10824 126976 0 0 as
Jun 27 01:31:20 kernel: [ 528047] 532 528047 903 181 45056 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 528048] 532 528048 129767 125905 1085440 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 528049] 532 528049 3019 2629 61440 0 0 as
Jun 27 01:31:20 kernel: [ 528862] 532 528862 903 194 45056 0 0 x86_64-alt-linu
Jun 27 01:31:20 kernel: [ 528863] 532 528863 79906 73367 671744 0 0 cc1plus
Jun 27 01:31:20 kernel: [ 528864] 532 528864 2326 1903 53248 0 0 as
Jun 27 01:31:20 kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=wasp03,mems_allowed=0-7,oom_memcg=/user/wasp/wasp03,task_memcg=/user/wasp/wasp03,task=cc1plus,pid=523910,uid=532
Jun 27 01:31:20 kernel: Memory cgroup out of memory: Killed process 523910 (cc1plus) total-vm:1046176kB, anon-rss:993012kB, file-rss:4kB, shmem-rss:23100kB, UID:532 pgtables:2072kB oom_score_adj:0
Jun 27 01:31:20 kernel: oom_reaper: reaped process 523910 (cc1plus), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
--
ldv
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 10:03 ` Dmitry V. Levin
@ 2020-06-27 10:16 ` Andrey Savchenko
2020-06-27 11:31 ` [devel] beehive memory management Anton Farygin
0 siblings, 1 reply; 16+ messages in thread
From: Andrey Savchenko @ 2020-06-27 10:16 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
On Sat, 27 Jun 2020 13:03:22 +0300 Dmitry V. Levin wrote:
> On Sat, Jun 27, 2020 at 10:21:47AM +0300, Anton Farygin wrote:
> > Я прошу ещё раз обратить внимание разработчиков beehive, что такое
> > поведение неприемлемо.
> >
> > Данный пакет отлично собирается как в сборочнице так и локально. Удалять
> > работающие пакеты из репозитория по причине того, что с ними не
> > спавляется beehive крайне некорректно.
>
> beehive и girar - это одна и та же сборочница.
Раз памяти хватает в girar, но не хватает в beehive — то уже не
одна и та же.
> Логи тестовой пересборки общедоступны.
Но ведь в логах есть не всё, что в общем случае необходимо для
отладки. Я уже попадал в такую ситуацию.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 9:44 ` Anton Farygin
@ 2020-06-27 10:23 ` Dmitry V. Levin
2020-06-27 11:17 ` Anton Farygin
0 siblings, 1 reply; 16+ messages in thread
From: Dmitry V. Levin @ 2020-06-27 10:23 UTC (permalink / raw)
To: ALT Devel discussion list
On Sat, Jun 27, 2020 at 12:44:48PM +0300, Anton Farygin wrote:
[...]
> collect2: fatal error: ld terminated with signal 9 [Killed]
> compilation terminated.
> И как мне это прикажете чинить ? уменьшить количество потоков в
> параллельной сборке - тогда локально будет плохо.
У тебя во время основной сборки используется -j32 и расходуется 52G памяти,
а во время тестовой пересборки используется -j8 и не хватает 32G памяти.
> Да и опять же - увеличьте количество памяти.
Больше памяти сперва надо заработать. :)
> Есть ли возможность как-то сдетектить, что сборка выполняется в окружении beehive ?
if [ "$(nproc)" -lt "$(nproc --all)" ]; then
: cpu limited build
fi
Это не beehive, это любая разновидность cpu limited build.
--
ldv
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 10:23 ` Dmitry V. Levin
@ 2020-06-27 11:17 ` Anton Farygin
2020-06-27 14:52 ` Vitaly Lipatov
0 siblings, 1 reply; 16+ messages in thread
From: Anton Farygin @ 2020-06-27 11:17 UTC (permalink / raw)
To: devel
On 27.06.2020 13:23, Dmitry V. Levin wrote:
> On Sat, Jun 27, 2020 at 12:44:48PM +0300, Anton Farygin wrote:
> [...]
>> collect2: fatal error: ld terminated with signal 9 [Killed]
>> compilation terminated.
>> И как мне это прикажете чинить ? уменьшить количество потоков в
>> параллельной сборке - тогда локально будет плохо.
> У тебя во время основной сборки используется -j32 и расходуется 52G памяти,
> а во время тестовой пересборки используется -j8 и не хватает 32G памяти.
Ну если на основной сборке получается взять 52G ОЗУ, а на тестовой -
нет, то это не одно и тоже и удалять пакет из репозитория по причине
того, что он не собирается в ограниченном окружении - нельзя.
Я уверен, что у нас есть масса пакетов, которые не соберутся при 16Gb ОЗУ.
>
>> Да и опять же - увеличьте количество памяти.
> Больше памяти сперва надо заработать. :)
есть отличная штука zram, память для бедных. Ну или как вариант,
рисовать исключения для пакетов, которые не помещаются в beehive, сам
понимаешь - борьба с ветряными мельницами отъедает время, которое можно
было потратить на что-то более полезное.
>
>> Есть ли возможность как-то сдетектить, что сборка выполняется в окружении beehive ?
> if [ "$(nproc)" -lt "$(nproc --all)" ]; then
> : cpu limited build
> fi
>
> Это не beehive, это любая разновидность cpu limited build.
Я понимаю, но мне важно научится отличать beehive от girar.
Как в процессе сборки подстроится под окружение ? Можно ли как-то
увидеть, сколько памяти есть в beehive во время сборки, и, например,
уменьшить nproc ?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] beehive memory management
2020-06-27 10:16 ` Andrey Savchenko
@ 2020-06-27 11:31 ` Anton Farygin
2020-06-29 6:00 ` Mikhail Novosyolov
2020-06-29 7:17 ` Michael Shigorin
0 siblings, 2 replies; 16+ messages in thread
From: Anton Farygin @ 2020-06-27 11:31 UTC (permalink / raw)
To: devel
On 27.06.2020 13:16, Andrey Savchenko wrote:
> On Sat, 27 Jun 2020 13:03:22 +0300 Dmitry V. Levin wrote:
>> On Sat, Jun 27, 2020 at 10:21:47AM +0300, Anton Farygin wrote:
>>> Я прошу ещё раз обратить внимание разработчиков beehive, что такое
>>> поведение неприемлемо.
>>>
>>> Данный пакет отлично собирается как в сборочнице так и локально. Удалять
>>> работающие пакеты из репозитория по причине того, что с ними не
>>> спавляется beehive крайне некорректно.
>> beehive и girar - это одна и та же сборочница.
А как она может быть одна и та-же, если у тебя физически оборудование
разное ?
> Раз памяти хватает в girar, но не хватает в beehive — то уже не
> одна и та же.
>
Может быть, нам стоит внедрить ещё один тип сборочных зависимостей?
Например, BuildRequires: memory(ram) > 52
И в rpmbuild детектить объём доступной для сборки памяти и провайдить
его как memory(ram) = 32 (для примера с beehive)
Сборка в этом случае даже не начнётся, ну и в принципе можно
подстроиться на стороне (пере)сборочницы под требования пакета к ОЗУ.
Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ
под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.
https://www.kernel.org/doc/Documentation/blockdev/zram.txt
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 11:17 ` Anton Farygin
@ 2020-06-27 14:52 ` Vitaly Lipatov
2020-06-28 12:35 ` Anton Farygin
0 siblings, 1 reply; 16+ messages in thread
From: Vitaly Lipatov @ 2020-06-27 14:52 UTC (permalink / raw)
To: ALT Linux Team development discussions
Anton Farygin писал 27.6.20 14:17:
...
> Как в процессе сборки подстроится под окружение ? Можно ли как-то
> увидеть, сколько памяти есть в beehive во время сборки, и, например,
> уменьшить nproc ?
Если посмотреть на пример со сборкой Телеграма:
BuildRequires(pre): rpm-build-intro >= 2.1.5
# use no more than system_memory/3000 build procs (see
https://bugzilla.altlinux.org/show_bug.cgi?id=35112)
%_tune_parallel_build_by_procsize 3000
--
С уважением,
Виталий Липатов,
ALT Linux Team
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-27 14:52 ` Vitaly Lipatov
@ 2020-06-28 12:35 ` Anton Farygin
2020-06-29 12:36 ` Vitaly Lipatov
0 siblings, 1 reply; 16+ messages in thread
From: Anton Farygin @ 2020-06-28 12:35 UTC (permalink / raw)
To: devel
On 27.06.2020 17:52, Vitaly Lipatov wrote:
> Anton Farygin писал 27.6.20 14:17:
> ...
>> Как в процессе сборки подстроится под окружение ? Можно ли как-то
>> увидеть, сколько памяти есть в beehive во время сборки, и, например,
>> уменьшить nproc ?
>
> Если посмотреть на пример со сборкой Телеграма:
>
> BuildRequires(pre): rpm-build-intro >= 2.1.5
>
> # use no more than system_memory/3000 build procs (see
> https://bugzilla.altlinux.org/show_bug.cgi?id=35112)
> %_tune_parallel_build_by_procsize 3000
>
>
Нет, это другая история.
Может быть beehive смог бы научиться учитывать объём памяти, потраченный
на сборку в girar и использовать именно его для воспроизведения сборки ?
Наверняка есть пакеты, которым было нужно меньше 32Gb ОЗУ.
В этом случае количество одновременно работающих потоков может зависеть
от количества свободной памяти и регулироваться динамически.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] beehive memory management
2020-06-27 11:31 ` [devel] beehive memory management Anton Farygin
@ 2020-06-29 6:00 ` Mikhail Novosyolov
2020-06-29 8:42 ` Anton Farygin
2020-06-29 7:17 ` Michael Shigorin
1 sibling, 1 reply; 16+ messages in thread
From: Mikhail Novosyolov @ 2020-06-29 6:00 UTC (permalink / raw)
To: devel
27.06.2020 14:31, Anton Farygin пишет:
> Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.
>
> https://www.kernel.org/doc/Documentation/blockdev/zram.txt
А как это отразится на производительности сборок, когда ЦП будет занят в т.ч. zram?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] beehive memory management
2020-06-27 11:31 ` [devel] beehive memory management Anton Farygin
2020-06-29 6:00 ` Mikhail Novosyolov
@ 2020-06-29 7:17 ` Michael Shigorin
2020-06-29 8:44 ` Anton Farygin
1 sibling, 1 reply; 16+ messages in thread
From: Michael Shigorin @ 2020-06-29 7:17 UTC (permalink / raw)
To: devel
On Sat, Jun 27, 2020 at 02:31:36PM +0300, Anton Farygin wrote:
> Может быть, нам стоит внедрить ещё один тип сборочных зависимостей?
> Например, BuildRequires: memory(ram) > 52
> И в rpmbuild детектить объём доступной для сборки памяти и провайдить
> его как memory(ram) = 32 (для примера с beehive)
Я что-то подобное предлагал уже давно, вместе со (словесным)
предложением фиксировать в сборочнице хотя бы примерное
потребление памяти/процессора (например, то, что даёт
time -f "%PCPU %Mk") -- чтоб статистика _уже_ капала:
https://lits.altlinux.org/pipermail/devel/2018-April/204248.html
> Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ
> под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.
> https://www.kernel.org/doc/Documentation/blockdev/zram.txt
Да, в условиях бездисковых/бессвоповых сборочных узлов и типовой
избыточности процессорных ядер относительно памяти это хороший
вариант. Обкатывали на клиентах LTSP ещё в 4.0. Ну и:
http://lists.altlinux.org/pipermail/devel/2018-April/204292.html
--
---- WBR, Michael Shigorin / http://altlinux.org
------ http://opennet.ru / http://anna-news.info
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] beehive memory management
2020-06-29 6:00 ` Mikhail Novosyolov
@ 2020-06-29 8:42 ` Anton Farygin
0 siblings, 0 replies; 16+ messages in thread
From: Anton Farygin @ 2020-06-29 8:42 UTC (permalink / raw)
To: devel
On 29.06.2020 09:00, Mikhail Novosyolov wrote:
> 27.06.2020 14:31, Anton Farygin пишет:
>> Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.
>>
>> https://www.kernel.org/doc/Documentation/blockdev/zram.txt
> А как это отразится на производительности сборок, когда ЦП будет занят в т.ч. zram?
>
Это хороший вопрос, который требует практического изучения
(тестирования) на beehive.
С высокой долей вероятности нагрузка на CPU будет не критичной.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] beehive memory management
2020-06-29 7:17 ` Michael Shigorin
@ 2020-06-29 8:44 ` Anton Farygin
0 siblings, 0 replies; 16+ messages in thread
From: Anton Farygin @ 2020-06-29 8:44 UTC (permalink / raw)
To: devel
On 29.06.2020 10:17, Michael Shigorin wrote:
> On Sat, Jun 27, 2020 at 02:31:36PM +0300, Anton Farygin wrote:
>> Может быть, нам стоит внедрить ещё один тип сборочных зависимостей?
>> Например, BuildRequires: memory(ram) > 52
>> И в rpmbuild детектить объём доступной для сборки памяти и провайдить
>> его как memory(ram) = 32 (для примера с beehive)
> Я что-то подобное предлагал уже давно, вместе со (словесным)
> предложением фиксировать в сборочнице хотя бы примерное
> потребление памяти/процессора (например, то, что даёт
> time -f "%PCPU %Mk") -- чтоб статистика _уже_ капала:
> https://lits.altlinux.org/pipermail/devel/2018-April/204248.html
time фиксируется, но потребление памяти на сборку складывается из диска
(tmpfs) + ОЗУ.
В случае с clickhouse ОЗУ нужно около 8Gb, остальное - диск.
>
>> Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ
>> под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.
>> https://www.kernel.org/doc/Documentation/blockdev/zram.txt
> Да, в условиях бездисковых/бессвоповых сборочных узлов и типовой
> избыточности процессорных ядер относительно памяти это хороший
> вариант. Обкатывали на клиентах LTSP ещё в 4.0. Ну и:
> http://lists.altlinux.org/pipermail/devel/2018-April/204292.html
Надо проверять на стороне сборочницы. Что будет выгоднее - zram +
увеличение количества потоков на сборку или уменьшение количества
параллельных потоков + увеличение ОЗУ на один.
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-28 12:35 ` Anton Farygin
@ 2020-06-29 12:36 ` Vitaly Lipatov
2020-06-29 12:54 ` Такасеев Алексей Геннадиевич
0 siblings, 1 reply; 16+ messages in thread
From: Vitaly Lipatov @ 2020-06-29 12:36 UTC (permalink / raw)
To: ALT Linux Team development discussions; +Cc: rider
Anton Farygin писал 28.6.20 15:35:
> On 27.06.2020 17:52, Vitaly Lipatov wrote:
>> Anton Farygin писал 27.6.20 14:17:
>> ...
>>> Как в процессе сборки подстроится под окружение ? Можно ли как-то
>>> увидеть, сколько памяти есть в beehive во время сборки, и, например,
>>> уменьшить nproc ?
>>
>> Если посмотреть на пример со сборкой Телеграма:
>>
>> BuildRequires(pre): rpm-build-intro >= 2.1.5
>>
>> # use no more than system_memory/3000 build procs (see
>> https://bugzilla.altlinux.org/show_bug.cgi?id=35112)
>> %_tune_parallel_build_by_procsize 3000
>>
>>
> Нет, это другая история.
В смысле другая история? Это именно о том, как регулировать количество
потоков в зависимости от свободной памяти.
> Может быть beehive смог бы научиться учитывать объём памяти,
> потраченный на сборку в girar и использовать именно его для
> воспроизведения сборки ?
>
> Наверняка есть пакеты, которым было нужно меньше 32Gb ОЗУ.
>
> В этом случае количество одновременно работающих потоков может
> зависеть от количества свободной памяти и регулироваться динамически.
--
С уважением,
Виталий Липатов,
ALT Linux Team
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [devel] Fwd: [#254123] TESTED del=clickhouse
2020-06-29 12:36 ` Vitaly Lipatov
@ 2020-06-29 12:54 ` Такасеев Алексей Геннадиевич
0 siblings, 0 replies; 16+ messages in thread
From: Такасеев Алексей Геннадиевич @ 2020-06-29 12:54 UTC (permalink / raw)
To: ALT Linux Team development discussions
----- Исходное сообщение -----
> От: "Vitaly Lipatov" <lav@altlinux.ru>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>
> Копия: rider@basealt.ru
> Отправленные: Понедельник, 29 Июнь 2020 г 20:36:22
> Тема: Re: [devel] Fwd: [#254123] TESTED del=clickhouse
> Anton Farygin писал 28.6.20 15:35:
>> On 27.06.2020 17:52, Vitaly Lipatov wrote:
>>> Anton Farygin писал 27.6.20 14:17:
>>> ...
>>>> Как в процессе сборки подстроится под окружение ? Можно ли как-то
>>>> увидеть, сколько памяти есть в beehive во время сборки, и, например,
>>>> уменьшить nproc ?
>>>
>>> Если посмотреть на пример со сборкой Телеграма:
>>>
>>> BuildRequires(pre): rpm-build-intro >= 2.1.5
>>>
>>> # use no more than system_memory/3000 build procs (see
>>> https://bugzilla.altlinux.org/show_bug.cgi?id=35112)
>>> %_tune_parallel_build_by_procsize 3000
>>>
>>>
>> Нет, это другая история.
> В смысле другая история? Это именно о том, как регулировать количество
> потоков в зависимости от свободной памяти.
Тут не в потоках дело. При сборке clickhouse отжирает в tempfs пространство
результатами сборки. Там хоть в один поток гоняй, хоть в 128 результат будет
одинаковый.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-06-29 12:54 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-27 7:21 ` [devel] Fwd: [#254123] TESTED del=clickhouse Anton Farygin
2020-06-27 9:21 ` Andrey Savchenko
2020-06-27 9:44 ` Anton Farygin
2020-06-27 10:23 ` Dmitry V. Levin
2020-06-27 11:17 ` Anton Farygin
2020-06-27 14:52 ` Vitaly Lipatov
2020-06-28 12:35 ` Anton Farygin
2020-06-29 12:36 ` Vitaly Lipatov
2020-06-29 12:54 ` Такасеев Алексей Геннадиевич
2020-06-27 10:03 ` Dmitry V. Levin
2020-06-27 10:16 ` Andrey Savchenko
2020-06-27 11:31 ` [devel] beehive memory management Anton Farygin
2020-06-29 6:00 ` Mikhail Novosyolov
2020-06-29 8:42 ` Anton Farygin
2020-06-29 7:17 ` Michael Shigorin
2020-06-29 8:44 ` Anton Farygin
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git