On Mon, Jan 18, 2010 at 17:30, Ville Skyttä ville.skytta@iki.fi wrote:
On Monday 18 January 2010, Seth Vidal wrote:
On Mon, 18 Jan 2010, Farkas Levente wrote:
the real bottleneck is not the rpmbuild itself (with ccache it cab be very fast), but the mock surroundings. suppose there is build which takes about 2 minutes and in mock it takes about 5 minutes:-( most of the time is in yum, python tar, gzip etc which all use only one cpu/core and it's very slow!
the tar and gzip are mostly BUILDING the cache.
I've been using lzop as the root cache compressor, it makes a difference over gzip here, especially when compressing the cache, but somewhat also when decompressing it. Add this to /etc/mock/site-defaults.cfg to try it out:
config_opts['plugin_conf']['root_cache_opts']['compress_program'] = 'lzop' config_opts['plugin_conf']['root_cache_opts']['extension'] = '.lzo'
For boxes with multiple cores, pigz (and maybe even pbzip2) might be worth looking into. I haven't tried these myself.
why we compress at all? disk space is cheep. can we speed up mock to somehow totally disable compressing root_cache? it used the case but store and restore in an uncompressed way? thanks.
(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.
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.
On Sun, Apr 3, 2011 at 13:52, Ville Skyttä ville.skytta@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?
On 04/03/2011 03:41 PM, Farkas Levente wrote:
- 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
So that's 2.5 seconds for decompressing the root cache. If you want to tweak that further, I suspect that in your setup pigz could be faster because IIRC lzop does not utilize multiple cores.
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???)
Most commands unlock the build root at end and for them there is a "unlock buildroot" state change log entry there, but for some reason for example build and buildsrpm do not do that. I just added an "end" state change in mock git so an end marker is logged for all commands.
- setup 8 sec (what the setup means here?)
Rebuilding the srpm in chroot, extracting build dependencies from it, and installing those build dependencies + possibly configured additional ones.
On Sun, 03 Apr 2011 16:50:18 +0300 Ville Skyttä ville.skytta@iki.fi wrote:
Most commands unlock the build root at end and for them there is a "unlock buildroot" state change log entry there, but for some reason for example build and buildsrpm do not do that. I just added an "end" state change in mock git so an end marker is logged for all commands.
Thanks, I have no idea why we didn't have an 'end' state.
I took a quick look at whether it would be easy to add state duration calculation to the code but decided that doing so would add extra code for not much gain. It's easy enough to calculate it from the log output.
Clark
On 04/03/2011 03:41 PM, Farkas Levente wrote:
2011-04-03 14:34:19,471 - State Changed: cleaning yum metadata 2011-04-03 14:34:29,492 - State Changed: running yum
BTW 10 seconds for "cleaning yum metadata" sounds curious to me. I just did a few builds and in all of those it was pretty much instant, about 0.04 seconds each time.
On Sun, Apr 3, 2011 at 16:01, Ville Skyttä ville.skytta@iki.fi wrote:
On 04/03/2011 03:41 PM, Farkas Levente wrote:
2011-04-03 14:34:19,471 - State Changed: cleaning yum metadata 2011-04-03 14:34:29,492 - State Changed: running yum
BTW 10 seconds for "cleaning yum metadata" sounds curious to me. I just did a few builds and in all of those it was pretty much instant, about 0.04 seconds each time.
strange, two successive run gives this: -------------------------------- 2011-04-03 16:04:08,854 - Mock Version: 1.1.9 2011-04-03 16:04:08,855 - State Changed: unpacking root cache 2011-04-03 16:04:11,320 - State Changed: cleaning yum metadata 2011-04-03 16:04:11,335 - State Changed: running yum 2011-04-03 16:04:28,889 - State Changed: unlock buildroot 2011-04-03 16:04:28,934 - State Changed: setup 2011-04-03 16:04:36,125 - State Changed: build Sun Apr 3 16:04:44 CEST 2011 -------------------------------- 2011-04-03 16:05:17,255 - Mock Version: 1.1.9 2011-04-03 16:05:17,257 - State Changed: unpacking root cache 2011-04-03 16:05:19,760 - State Changed: cleaning yum metadata 2011-04-03 16:05:26,443 - State Changed: running yum 2011-04-03 16:05:35,512 - State Changed: unlock buildroot 2011-04-03 16:05:35,559 - State Changed: setup 2011-04-03 16:05:42,761 - State Changed: build Sun Apr 3 16:05:51 CEST 2011 -------------------------------- what make it really strange is "cleaning yum metadata" + "running yum" is about the same 16-17 sec which is one of the biggest time:-(
-- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
buildsys@lists.fedoraproject.org
-
Clark Williams -
Farkas Levente -
Ville Skyttä