# Where's my swap? (A "how does vSwap work" question)



## raindog308 (Feb 26, 2014)

On a RamNode OvZ:



```
# free -m
             total       used       free     shared    buffers     cached
Mem:           512        374        137          0          0        350
-/+ buffers/cache:         23        488
Swap:          512          1        510
# swapon -s
Filename                                Type            Size    Used    Priority
/dev/null                               partition       524288  1116    -1
```

Same thing on a BuyVM OvZ - /dev/null for swap.

 

Both these plans list vSwap and I don't think those providers are trying to cheat me   I'm wondering how the container sees/uses swap?  

 

So if it's, say, a 512/512 plan, Is the container allocated 1024MB of RAM (half physical RAM, half disk)?


----------



## mojeda (Feb 26, 2014)

I think with BuyVM you get 512MB and it's burstable to up to 1024MB???

Edit:

From BuyVM wiki:



> A dedicated resource is one the vps is guaranteed to get if requested; these are “yours.” Burst resources come from the remaining unused capacity of the system. The system may allow one VPS to borrow resources like RAM from another VPS when the second one is not using them, but as it is only borrowing, such resources should be returned as soon as possible.


For their OpenVZ plans I think it lists the Memory as Dedicated/Additional Burstable.


----------



## raindog308 (Feb 26, 2014)

mojeda said:


> I think with BuyVM you get 512MB and it's burstable to up to 1024MB???


Well the wiki says vSwap...

http://wiki.buyvm.net/doku.php/plans?s[]=vswap

Do you use vSwap on your plans?

As of June 2013 all OpenVZ plans support vSwap.

All virtual servers have been retroactively updated to have a 1:1 ratio for memory:vswap.


----------



## mojeda (Feb 26, 2014)

See my earlier post


----------



## DomainBop (Feb 26, 2014)

http://openvz.org/VSwap

http://openvz.livejournal.com/39644.html


----------



## KuJoe (Feb 26, 2014)

vSwap uses RAM and not actual swap on a disk like traditional swap (although OpenVZ will artificially slow it down so your vSwap is not at fast as your actual RAM). This is why it says /dev/null because there's no actual directory/file on the disk.


----------



## raindog308 (Feb 26, 2014)

DomainBop said:


> http://openvz.org/VSwap


OK, I _did_ read that 

But I was asking about the container OS.  Now that I think about it more, I guess the shared kernel knows that if it exceeds RAM and needs to swap, it shouldn't look at normal Linux swap config but rather the special OvZ setup.


----------



## tchen (Feb 26, 2014)

raindog308 said:


> On a RamNode OvZ:
> 
> 
> 
> ...


It probably helps to back up and remind ourselves that 'memory' is really just a block of virtual addresses (split into pages).  These pages can be either backed by RAM or disk with very little to tell the two apart from the requestor's perspective.  OpenVZ attempts to keep everything in physical RAM when possible, so you're actually getting 512+512 RAM each from different pools.

Internal to the container, when a 'swap' occurrence happens, pages from the user, kernel, page cache are copied into the virtual 'swapfile' and accounted for there.  The swapfile itself is comprised of memory pages on the host node.  That's typically RAM, and will only hit disk when itself gets really swapped out due to low memory on the host.

/dev/null in the container is just a placeholder and doesn't really matter.  Unlike a normal linux instance, this 'swapfile' isn't a real file by any means hence the stub.

When a swap-in occurs, the pages are read back from the virtual swapfile, not from /dev/null - just in case you're wondering.

P.S. Previous to OpenVZ's implementation of vSwap, you could still directly create a /dev/null fake swap.  That's different and is a blackhole.


----------

