Machine: Provision Swap

Created on 21 Mar 2015  路  7Comments  路  Source: docker/machine

I am having a problem with the Digital Ocean driver because it does not include any swap. Normally my RAM usage stays between 30-70% but occasionally it would spike such as when building a particular image causing the machine to become unresponsive. Of course I can manually SSH in and create a swapfile but that would not be practical with many machines in a Swarm so I'm wondering if it's possible to create the swapfile during provisioning to act as a buffer?

Most helpful comment

@hairyhenderson I made this one liner as a workaround without needing any additional tools.

for i in $(docker-machine ls | grep digitalocean | awk '{print $1}'); do docker-machine ssh $i -- ls /swapfile || docker-machine ssh $i "fallocate -l 512M /swapfile && chmod 400 /swapfile && mkswap /swapfile" && docker-machine ssh $i "swapon /swapfile && echo '/swapfile none swap defaults 0 0' >> /etc/fstab" &>/dev/null; done

All 7 comments

@UserTaken The image that's installed comes from DigitalOcean. Looks like their Ubuntu images (at least 14.04 and 14.10) don't include a swap partition. You might want to log a support ticket with them about that.

Also, Machine will eventually support cloudinit, so that would be the way to tweak the OS at provision time.

As a workaround, you could always use a tool like pssh (though I'm sure there are more recently-maintained tools) to issue ssh commands in parallel to all of the machines in the swarm.

@hairyhenderson I made this one liner as a workaround without needing any additional tools.

for i in $(docker-machine ls | grep digitalocean | awk '{print $1}'); do docker-machine ssh $i -- ls /swapfile || docker-machine ssh $i "fallocate -l 512M /swapfile && chmod 400 /swapfile && mkswap /swapfile" && docker-machine ssh $i "swapon /swapfile && echo '/swapfile none swap defaults 0 0' >> /etc/fstab" &>/dev/null; done

@UserTaken - I did a little bit more research on this over the weekend because I was curious ;)

All of DigitalOcean's droplets are SSD-based, and putting swap on SSD would really shorten the life of their hardware. So this explains why they have no swap by default.

I don't think there's anything wrong with your adding swap to your droplets, but just so you can be sure not to tax the SSDs too much, you should consider tweaking the swapiness settings. See http://en.wikipedia.org/wiki/Swappiness for more info on that. If you only need the swap rarely, consider setting it somewhere between 1 and 10. And if you end up swapping more often, you should really use a bigger droplet :)

@hairyhenderson

My normal usage level is within tolerance and the swapfile is just for the RAM be burstable so I think the default swappiness value is fine. I have not heard of cloudinit before but since DigitalOcean is not going to add swap to their droplets, Machine will be able to add a swapfile when provisioning in the future?

I opened a support ticket with DigitalOcean and the reply was as expected in that they will not include a swapfile/partition by default. All the other drivers I've used include swap so I think it will be beneficial to provisioning some during droplet creation. In the meanwhile I have been using

$ for i in $(docker-machine ls | grep digitalocean | awk '{print $1}'); \
    do printf "\x1B[01;33m\n$i\n\x1B[0m" && docker-machine ssh $i ls /swapfile || \
    docker-machine ssh $i -- \
    "fallocate -l 1G /swapfile && chmod 600 /swapfile && mkswap /swapfile && \
    echo -e '\n/swapfile none swap defaults 0 0' >> /etc/fstab && swapon -a && free -htl"; done

@UserTaken - Docker Machine's goal is to get a VM provisioned with Docker, configured in a _reasonable_ way for _most_ production use-cases. There are plans to allow more flexibility (such as cloudinit support, as well as plugin support), but those are probably a few months away.

As for modifying the DigitalOcean driver in Docker Machine to be able to configure a swap file, I think that's probably out of scope (though, that's not my decision).

/cc @ehazlett

I agree with @hairyhenderson. We use the provider's default operations for the "normal" case because they tend to know what is best for them. Like @hairyhenderson also said, we want to eventually support cloudinit which would let you do just about anything to the VM. This should offer the most flexibility. Thanks for the feedback!

Was this page helpful?
0 / 5 - 0 ratings