From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20200627055238.GA29429@gyle.altlinux.org> <20200627100322.GA17801@altlinux.org> <20200627131656.dea598cce8bcedff64df3075@altlinux.org> <20200629071730.GF16723@imap.altlinux.org> From: Anton Farygin X-Opacus-Archived: none Organization: BaseALT Message-ID: <6971ad35-3a92-f9ac-7565-e6a6f3244add@basealt.ru> Date: Mon, 29 Jun 2020 11:44:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200629071730.GF16723@imap.altlinux.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] beehive memory management X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 08:44:39 -0000 Archived-At: List-Archive: List-Post: 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 + увеличение количества потоков на сборку или уменьшение количества параллельных потоков + увеличение ОЗУ на один. >