On Sun, Apr 3, 2011 at 13:52, Ville Skyttä <ville.skytta(a)iki.fi> wrote:
(Not sure why this is cross-posted to devel, dropping it.)
On 04/03/2011 01:31 PM, Farkas Levente wrote:
> disk space is cheep.
Traditional rotational disk space is.
even ssd is cheaper than time:-)
> can we speed up mock to
> somehow totally disable compressing root_cache?
Whether it speeds it up depends on how much CPU and disk I/O resources
the box has, but you can disable compression of the root cache by
setting compress_program to an empty string in mock's config.
On the box I have in front of me (single core Athlon64 3200+, pretty
fast SSD) the step where mock unpacks the F-14 root cache takes slightly
less than 5 seconds if it's lzop compressed, and slightly more than 3 if
it's not compressed. pigz would be about 6 seconds and has somewhat
better compression than lzop but it's so much slower than lzop whenever
the root cache needs to be rebuilt (compressing it takes ~40 seconds
with pigz and gzip, ~7 with lzop) that it annoys me. Anyway, compared
to common setups, I suspect the disk I/O vs CPU ratio of this box is
biased towards the former, and on this box I'll gladly take the root
cache size savings and pay the price of ~2 seconds per build for it.
I suggest you benchmark and find out what works best for you. An easy
way to get approximate numbers is by looking into mock's state.log.
so on a
- Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
- ADATA SSD S599 64GB
- 4GB ram
if i switch lzop and build tzdata-2011d-3.el5.src.rpm:
------------------------------
2011-04-03 14:34:16,898 - Mock Version: 1.1.9
2011-04-03 14:34:16,900 - State Changed: unpacking root cache
2011-04-03 14:34:19,471 - State Changed: cleaning yum metadata
2011-04-03 14:34:29,492 - State Changed: running yum
2011-04-03 14:34:32,939 - State Changed: unlock buildroot
2011-04-03 14:34:32,983 - State Changed: setup
2011-04-03 14:34:40,188 - State Changed: build
Sun Apr 3 14:34:48 CEST 2011
------------------------------
the last line is a date output since mock doesn't log the build finish
time (why not???)
so it seems the build (ie the rpmbuild itself) with a prebuild cache:
- unpack root 2.5 sec
- yum 13 sec
- setup 8 sec (what the setup means here?)
- build 8 sec
i don't know whether it's worth to use tmpfs and /dev/shm and where?
or both together?
for what tmpfs good and used for (there is no tmpfs_opts dir so sued for what)?
anyway the question now hoe to seepd up yum and setup (and what's setup?
--
Levente "Si vis pacem para bellum!"