From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 29 Jun 2020 10:17:30 +0300 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20200629071730.GF16723@imap.altlinux.org> References: <20200627055238.GA29429@gyle.altlinux.org> <20200627100322.GA17801@altlinux.org> <20200627131656.dea598cce8bcedff64df3075@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 07:17:30 -0000 Archived-At: List-Archive: List-Post: 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