How to check overbooking of OpenVZ VPS and Xen VPS

Whether you are in OpenVZ or Xen environment, there is no question of "oversubscription", but whether it is serious. If it is serious, it becomes "OVERLOAD", which means the server is overloaded. Therefore, when you purchase, don’t think that there is a place to buy a cheap VPS that is not oversold. That's impossible.
The price of a VPS that is not oversold for one month may be the price of your cheap VPS for half a year or a year.
Check out the oversell method of OpenVZ VPS:

Enter the shared memory directory of Linux:
cd /dev/shm
Create a 100MB file:
dd if=/dev/zero of=./memtest bs=1M count=100
Check the memory:
free -m
You can see that the memory usage has increased by 100MB.
As long as the provider's memory quota is not exceeded,
Keep increasing the count value in the create file command.
You can see the memory growth.
If the machine breaks down within the promised memory, it is a serious oversale.
At the end, enter:
rm ./memtest
other:
View CPU information:
cat /proc/cpuinfo
Disk IO test command
dd if=/dev/zero of=test bs=64k count=512 oflag=dsync
Port Speed Test
wget http://cachefly.cachefly.net/100mb.test
1) Check the process memory usage
top
2) Check CPU information
cat /proc/cpuinfo
3) Disk IO test command
dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
4) Port speed test
wget http://cachefly.cachefly.net/100mb.test
5) View Inode
df -i
6) Memory oversubscription check Enter the shared memory directory of Linux:
cd /dev/shm
Create a 100MB file:
dd if=/dev/zero of=./memtest bs=1M count=100
Check the memory:
free -m
At the end, enter:
rm ./memtest

Check out how to oversell Xen VPS:

Previously purchased a Xen VPS with 512MB of memory
The price is also cheap. So, I logged in and checked how much memory was.
run
# free
total used free shared buffers cached
Mem: 543776 535360 8416 0 66516 130504
-/+ buffers/cache: 338340 205436
Swap: 1048568 136 1048432
330MB of RAM is already available for my new Xen VPS. "Let's see what processes are running
# ps aux
…
root 204 0.0 0.1 17028 780 ? S Oct27 0:00 upstart-udev-bridge --daemon 102 356 0.0 0.1 23548 1080 ? Ss Oct27 0:00 dbus-daemon --system --fork root 431 0.0 0.1 21068 788 ? Ss Oct27 0:00 cron root 3110 0.0 0.5 253832 2992 ? Sl Oct28 0:00 /usr/sbin/console-kit-daemon --no-daemon root 11037 0.0 0.1 49256 1012 ? Ss Oct28 0:00 /usr/sbin/sshd root 15427 0.0 0.1 12520 772 ? S Oct28 0:00 /usr/sbin/syslogd --no-forward root 31231 0.0 0.0 16748 436 ? Ss Nov12 0:00 udevd --daemon root 5716 0.0 0.6 79100 3772 ? Ss 01:02 0:00 sshd: [email protected]/0 root 5731 0.0 0.3 19400 2148 pts/0 Ss 01:02 0:00 -bash root 5782 0.0 0.1 6072 724 ? Ss 01:08 0:00 /sbin/getty -8 38400 hvc0 root 5783 0.0 0.2 15248 1172 pts/0 R+ 01:08 0:00 ps --sort=start_time uax
There is not much memory running on the VPS. SSH server, syslogd, cron
So why did 330MB of memory that I wasn't using disappear?
Let's dig further before we arrive at this certification.
You can be sure of the answer: the Xen VPS's memory is oversold. This has been known to many people for many years and it uses a technique called "ballooning".
Basically a special Linux kernel driver is installed on your system – the “balloon driver”.
When dom0 (the Xen server/hypervisor) needs more memory and wants to request it from the (domU) guest VPS, it will ask the guest VPS's "balloon driver" to act as itself
– by asking its Linux kernel for some memory. Kernel memory allocation will be required to the VPS system available memory and cannot be paged out to swap.
The host once bloated consumes memory and then passes it to dom0/hypervisor for use elsewhere (such as setting up a new VPS).
Therefore, your VPS's "Total Memory" will remain the same, but will have a large increase in "Memory Used", as a large chunk will already be used by the kernel balloon driver.