I have overlay2 and super fast disk I/O (memory cheat + SSD), just the CPU freq is not high. The CPU is a Broadwell and actually it has lot more core (E5-2630V4). Even a 5 year old gamer CPU can be 2 times faster on a single core, but cannot compete with all of the cores ;-)
This machine have seen faster setup time, but I'll return to this in an another topic. On Tue, Sep 26, 2017 at 6:16 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > On 26 September 2017 at 07:34, Attila Fazekas <afaze...@redhat.com> wrote: > > decompressing those registry tar.gz takes ~0.5 min on 2.2 GHz CPU. > > > > Fully pulling all container takes something like ~4.5 min (from > localhost, > > one leaf request at a time), > > but on the gate vm we usually have 4 core, > > so it is possible to go bellow 2 min with better pulling strategy, > > unless we hit some disk limit. > > Check your $docker info. If you kept defaults, storage driver will be > devicemapper on loopback, which is awfully slow and not very reliable. > Overlay2 is much better and should speed things up quite a bit. For me > deployment of 5 node openstack on vms similar to gate took 6min (I had > registry available in same network). Also if you pull single image it > will download all base images as well, so next one will be > significantly faster. > > > > > On Sat, Sep 23, 2017 at 5:12 AM, Michał Jastrzębski <inc...@gmail.com> > > wrote: > >> > >> On 22 September 2017 at 17:21, Paul Belanger <pabelan...@redhat.com> > >> wrote: > >> > On Fri, Sep 22, 2017 at 02:31:20PM +0000, Jeremy Stanley wrote: > >> >> On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote: > >> >> > "if DevStack gets custom images prepped to make its jobs > >> >> > run faster, won't Triple-O, Kolla, et cetera want the same and > where > >> >> > do we draw that line?). " > >> >> > > >> >> > IMHO we can try to have only one big image per distribution, > >> >> > where the packages are the union of the packages requested by all > >> >> > team, > >> >> > minus the packages blacklisted by any team. > >> >> [...] > >> >> > >> >> Until you realize that some projects want packages from UCA, from > >> >> RDO, from EPEL, from third-party package repositories. Version > >> >> conflicts mean they'll still spend time uninstalling the versions > >> >> they don't want and downloading/installing the ones they do so we > >> >> have to optimize for one particular set and make the rest > >> >> second-class citizens in that scenario. > >> >> > >> >> Also, preinstalling packages means we _don't_ test that projects > >> >> actually properly declare their system-level dependencies any > >> >> longer. I don't know if anyone's concerned about that currently, but > >> >> it used to be the case that we'd regularly add/break the package > >> >> dependency declarations in DevStack because of running on images > >> >> where the things it expected were preinstalled. > >> >> -- > >> >> Jeremy Stanley > >> > > >> > +1 > >> > > >> > We spend a lot of effort trying to keep the 6 images we have in > nodepool > >> > working > >> > today, I can't imagine how much work it would be to start adding more > >> > images per > >> > project. > >> > > >> > Personally, I'd like to audit things again once we roll out zuulv3, I > am > >> > sure > >> > there are some tweaks we could make to help speed up things. > >> > >> I don't understand, why would you add images per project? We have all > >> the images there.. What I'm talking about is to leverage what we'll > >> have soon (registry) to lower time of gates/DIB infra requirements > >> (DIB would hardly need to refresh images...) > >> > >> > > >> > ____________________________________________________________ > ______________ > >> > OpenStack Development Mailing List (not for usage questions) > >> > Unsubscribe: > >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> ____________________________________________________________ > ______________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev