On 03/14/2014 02:22 PM, Parameswaran Sivatharman wrote:
> @Andy: Only difference that I can think of why it took significantly
> different times is that they could have probably used different archive
> locations: http://az3.clouds.archive.ubuntu.com vs
> http://archive.ubuntu.com/ubuntu/ and the latter might have been too
> slow at the time. The apt-get update within the chroot is hitting the
> latter but on the instance it's hitting the az3.cloud one.
Its not happening anymore, so I think it was just temporary LP insanity
> Also there is a zerofile creation/removal step that's used to speed up
> the compression in the image-builder and this used to make the process
> slow but after increasing the RAM I have not seen it. From the logs
> it's not clear whether this was the case.
This was purely in apt-get-install. The compression step ran pretty fast.
On 03/14/2014 02:22 PM, Parameswaran Sivatharman wrote: az3.clouds. archive. ubuntu. com vs archive. ubuntu. com/ubuntu/ and the latter might have been too
> @Andy: Only difference that I can think of why it took significantly
> different times is that they could have probably used different archive
> locations: http://
> http://
> slow at the time. The apt-get update within the chroot is hitting the
> latter but on the instance it's hitting the az3.cloud one.
Its not happening anymore, so I think it was just temporary LP insanity
> Also there is a zerofile creation/removal step that's used to speed up
> the compression in the image-builder and this used to make the process
> slow but after increasing the RAM I have not seen it. From the logs
> it's not clear whether this was the case.
This was purely in apt-get-install. The compression step ran pretty fast.