default uec-image requires at least 300 M of RAM to run - m1.small and c1.medium not needed by default

Two different issues here: the inflation of the minimal RAM amount needed to run a lucid cloud image, and a redefinition of the default VM types to better reflect the default use case. I think it's important to keep the memory usage in our cloud images to a minimum if possible and 300Mb sounds quite large as a minimum to me.

I'll open a vmbuilder task to track the first issue, even if it's likely not to be a vmbuilder issue, feel free to change the affected package when the cause is better defined.

Mathias, how have you determined this 300 MB requirement?

300 is high, but this bug is made worse by bug 499522 which will be fixed soon (fixed in my developement ec2-init).

On Fri, Jan 15, 2010 at 12:38:43PM -0000, Soren Hansen wrote:
> Mathias, how have you determined this 300 MB requirement?
>

IIRC, I've booted a default UEC image and then looked at top just after boot.
Swap space was used. And there was around 30-40 M of free RAM. Not very
scientific though.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

On Fri, Jan 15, 2010 at 04:37:38PM -0000, Mathias Gug wrote:
> On Fri, Jan 15, 2010 at 12:38:43PM -0000, Soren Hansen wrote:
> > Mathias, how have you determined this 300 MB requirement?
> IIRC, I've booted a default UEC image and then looked at top just
> after boot. Swap space was used. And there was around 30-40 M of free
> RAM. Not very scientific though.

If you get the chance, could you grab a "ps -eFl" and dump it here for
analysis? I'm really curious where all that memory is being spent.

$ free
             total used free shared buffers cached
Mem: 1759664 251192 1508472 0 3460 41492
-/+ buffers/cache: 206240 1553424

I'm elevating the eucalyptus task here to "High" (which might be a bit ambitious), but I'm also targeting at A3.

I've been doing some scalability testing on my 5-node cluster, each node having 4GB of memory. I'm able to run up to 14 x 256MB guests per node. It would be nice to get a few more on there.

Still, I think we should at least have a good look at our default instance sizes, and just review them if nothing else (perhaps just closing this bug). This is a task for the distro sprint next week.

:-Dustin

To be clear, the issue here is more than just accounting. When we boot an instance in UEC with 256M or less of memory, the OOM kicks in and the system is generally not in good shape.

looking into this further, the big difference between karmic and lucid /proc/meminfo was 'LowFree'. On an ec2 instance with 2G memory, I saw:
 Karmic: 681616
 Lucid: 552616

That lead me to suspect ureadahead. It turns out, that if I remove ureadahead from the instance, I can boot in 96M of memory under kvm. With ureadahead in the instance, I get OOM messages at 256M.

One thing to note, is that this is a fresh first-boot of ec2 instance. ureadahead has never profiled before, and can't be expected to have.

Fixed images are running fine with 128Mb RAM, nothing should be changed in Eucalyptus ?
I think we should disable ureadahead in cloud images, doesn't make much sense in a system that will rarely be booted twice ?
Opening a ureadahead task, maybe it shouldn't better adapt to the amount of RAM available ?

This is being fixed by diverting the /etc/init/ureadahead.conf conffile in a postinst script for cloud-init.

This bug was fixed in the package cloud-init - 0.5.3-0ubuntu2

---------------
cloud-init (0.5.3-0ubuntu2) lucid; urgency=low

  * divert ureadahead.conf in postinst (LP: #499520)
  * lintian cleanups
 -- Scott Moser <email address hidden> Fri, 05 Feb 2010 15:48:21 -0500

Verified this is present in 20100210 build.

$ ls -l /etc/init/ureadahead*
-rw-r--r-- 1 root root 889 2009-12-21 23:27 /etc/init/ureadahead.conf.disabled
-rw-r--r-- 1 root root 683 2009-12-21 23:27 /etc/init/ureadahead-other.conf
$ dpkg-divert --listpackage /etc/init/ureadahead.conf
cloud-init
$ dpkg-query --show cloud-init
cloud-init 0.5.3-0ubuntu2