Swap bash script pins htop's memory usage

Question

I deployed a hack to add swap space to a VPS that otherwise didn't allow me to use swapon to create a file.

Prior to adding and executing the script, I followed the steps outlined here. and summarized below:

1. First I create the swap file: sudo dd if=/dev/zero of=/swapfile bs=1024 count=512k
2. Then sudo mkswap /swapfile.
3. The next step would usually have been to do a sudo swapon /swapfile. However, the VPS I'm using doesn't jive with that, so I found this post. That claimed I could use the following script as a workaround.

See below:

#!/bin/bash
SWAP="${1:-512}"
NEW="$[SWAP*1024]"; TEMP="${NEW//?/ }"; OLD="${TEMP:1}0"
umount /proc/meminfo 2> /dev/null
sed "/^Swap\(Total\|Free\):/s,$OLD,$NEW," /proc/meminfo > /etc/fake_meminfo
mount --bind /etc/fake_meminfo /proc/meminfo

For more context, the process is described in detail in this answer. (It's mostly just spoon-feeding on running a bash script.)

All seems to be fine, however when I look in htop (or in free -m for that matter); the memory usage remains at whatever value it was at when I executed the script and the used swap space remains at zero. This is regardless of whatever process I run on the server. My knowledge of what's going on in memory allocation is very limited (this is really my first time screwing around with it). Could anyone tell me if this makes sense, given the script I'm running, and why?

Answer 1

You have greatly misunderstood what that post means by "fake swap". There are some programs that for various reasons insist on a system having swap space enabled (cough Oracle cough). If it isn't, the program—or at least its installer—complains. Of course with the aforementioned database there are ways to tell it to continue anyway, but people often don't know them.

The "fake swap" you found is a workaround. It's a way to lie to those programs, and pretend swap is enabled. The swap is a lie. There is no actual swap. But the program believes there is, so it doesn't complain. The workaround also lies to free, etc., and lies about all the other values in /proc/meminfo as well. (Honestly: if I found this in use on a system I was using—much less administering—I'd use terms much harsher than "workaround". Terms that'd not be suitable for polite conversation.)

Tante's answer on the other question is probably correct: OpenVZ does not support swap on VMs. There is no alternative to swapon. It does a bunch of checks, but then calls the kernel's swapon syscall. If the syscall isn't supported, you're done. You can't do it. Sorry.

Depending on the actual problem you're trying to solve, there are some other approaches that may work:

• If a particular process needs to work with a huge amount of data, mmap probably still works. Or use more space-efficient algorithms.
• Allocate (or ask/pay the provider) more memory to the VM. Possibly enable swap on the host.
• Switch to a different virtualization solution, or to running on bare metal.
• You could probably run User Mode Linux inside your OpenVZ container. Inside that UML instance, you can probably enable swap. I fully expect performance to be terrible.

Answer 2

If I understand that script correctly, it doesn't actually enable swap in any way. Instead it just pretends that the system has swap by replacing /proc/meminfo so that free and htop believe that the system has swap, but the kernel is in no way able to use this fake swap. If you look at the script, you may notice that no swap file or partition is mentioned anywhere, so there isn't anything that the kernel could use.

So this:

swap space remains at zero

Is exactly what I would expect to happen.