SWAP File or SWAP Partition - VMWare VPS

NuLL3rr0r

NuLL3rr0r

Hi Folks,

I know generally the performance of SWAP Partitions are better than SWAP Files, specially if they resides on the beginning of the disk.

But inside an VMWare VPS, does this matter? Since that VMWare Virtual Disk simply is a file??

Generally I avoid using SWAP Space inside VM, but sometimes they are very useful; Like building software from Ports (I have difficulties with some packages without SWAP Space; Memory consuming GCC soon stops with some errors.).

http://ivoras.sharanet.org/freebsd/vmware.html
Code: 
4. Disable internal VMWare swapping
Consider disabling VMWare internal memory swapping and make the virtual machine fit in in 
the physical memory of the host for best performance. Of course, be informed on the impact 
of VMWare's memory management before you commit on doing this.


I've done a little benchmark using UnixBench with and without SWAP File. But since it's time consuming and cost demanding for me to reformat the tested VPS (It's a production server), restart from scratch and create a SWAP Partition, Does it worth? Does performance gain is that great?

Note that from the day one I formatted the whole 20 GB disk as one partition. On that moment I was thought if I need SWAP Space, simply I can use SWAP files. But I was never aware of such a huge difference [or at least before sending it to public never running some tests].

Here is the Spec & Result:


Code: 
FreeBSD 8.0 (VMWare ESXi 4.0 VPS)
384 MB Ram
Single CPU
20 GB H.D.D

Open-VM-Tools-noX11
kern.hz=50 in /boot/loader.conf


Code: 
SWAPPING Disabled
==============================================================
BYTE UNIX Benchmarks (Version 4.1-wht.2)
System -- FreeBSD 3rr0r.babaei.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 
16:02:27 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
/dev/da0s1a    20301670 2741446 15936092    15%    /

Start Benchmark Run: Fri Jan 22 15:53:50 CET 2010
 3:53PM  up 11:45, 1 user, load averages: 0.00, 0.00, 0.00

End Benchmark Run: Fri Jan 22 16:05:24 CET 2010
 4:05PM  up 11:57, 1 user, load averages: 13.72, 5.85, 2.82


                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7  6726822.6      178.5
Double-Precision Whetstone                      83.1     1677.0      201.8
Execl Throughput                               188.3      727.7       38.6
File Copy 1024 bufsize 2000 maxblocks         2672.0    33798.0      126.5
File Copy 256 bufsize 500 maxblocks           1077.0    22053.0      204.8
File Read 4096 bufsize 8000 maxblocks        15382.0   583159.0      379.1
Pipe Throughput                             111814.6  1003147.0       89.7
Pipe-based Context Switching                 15448.6   118393.1       76.6
Process Creation                               569.3     1465.9       25.7
Shell Scripts (8 concurrent)                    44.8      231.7       51.7
System Call Overhead                        114433.5   648172.5       56.6
                                                                 =========
     FINAL SCORE                                                      96.9


Code: 
768 MB SWAP File
==============================================================
BYTE UNIX Benchmarks (Version 4.1-wht.2)
System -- FreeBSD 3rr0r.babaei.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 
16:02:27 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
/dev/da0s1a    20301670 5297424 13380114    28%    /

Start Benchmark Run: Thu Mar 25 01:30:35 CET 2010
 1:30AM  up 15 days,  3:15, 1 user, load averages: 0.00, 0.00, 0.00

End Benchmark Run: Thu Mar 25 02:01:24 CET 2010
 2:01AM  up 15 days,  3:45, 1 user, load averages: 10.49, 4.42, 2.07


                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7  1993566.9       52.9
Double-Precision Whetstone                      83.1      491.7       59.2
Execl Throughput                               188.3      202.7       10.8
File Copy 1024 bufsize 2000 maxblocks         2672.0    16178.0       60.5
File Copy 256 bufsize 500 maxblocks           1077.0    16081.0      149.3
File Read 4096 bufsize 8000 maxblocks        15382.0   484252.0      314.8
Pipe Throughput                             111814.6   274621.3       24.6
Pipe-based Context Switching                 15448.6    32557.6       21.1
Process Creation                               569.3      379.6        6.7
Shell Scripts (8 concurrent)                    44.8       45.8       10.2
System Call Overhead                        114433.5   175847.7       15.4
                                                                 =========
     FINAL SCORE                                                      33.1


Best regards,
M.S. Babaei
 
NuLL3rr0r said:
Generally I avoid using SWAP Space inside VM, but sometimes they are very useful; Like building software from Ports (I have difficulties with some packages without SWAP Space; Memory consuming GCC soon stops with some errors.).
Click to expand...
Turning off swap completely will actually slow things down. Modern OSs need swap even if they have plenty of internal memory.

I would use the 'standard' swap partition.
 
SirDice said:
Turning off swap completely will actually slow things down. Modern OSs need swap even if they have plenty of internal memory.
Click to expand...

Are you serious? swap is crap.
If your OS ever touch swap, buy more RAM, if your OS does not touch swap buy even more RAM :)

If you want your HDD(or SSD) to die fast, just continue to use swap ...
 
richardpl said:
Are you serious? swap is crap.
Click to expand...
Yes, I am serious. Modern OS uses the MMU which, by definition means some things will get swapped.

If your OS ever touch swap, buy more RAM, if your OS does not touch swap buy even more RAM :)
Click to expand...
Wrong. Adding memory will only help if you have excessive paging in and out of swap.
Just data sitting in swap not doing anything isn't a problem.
 
Exactly. This is not at all uncommon:

Code: 
Mem: 146M Active, 1078M Inact, 219M Wired, 3124K Cache, 112M Buf, 555M Free
Swap: 4096M Total, 104M Used, 3992M Free, 2% Inuse

That 104M is rather static. It's been there for days. As far as I can see (I have a swap-backed tmpmfs), it's
Code: 
102074	/tmp/eaccelerator

Those are essentially static binaries that don't change for a long time, so "the system" has determined it doesn't have to occupy RAM any longer, flushing it to swap instead. I think most servers that have static information in RAM for a long time will swap some or all of it to disk and use RAM for dynamic content.
 
SirDice said:
Yes, I am serious. Modern OS uses the MMU which, by definition means some things will get swapped.


Wrong. Adding memory will only help if you have excessive paging in and out of swap.
Just data sitting in swap not doing anything isn't a problem.
Click to expand...

Wrong. Adding memory will always help if you can take advantage of more cached VM. Small static servers obviously do not need it.

I'm done for now. (Looks like I'm the only one who thinks about performance)
 
Speaking of performance. Writing to swap is much more simple and thus much less stressing for the disk than writing to any filesystem, even the simplest one. It's probably more stressing to write logs than to swap a few pages.
I almost never have more than a few hundred KBs on swap, and these disks I'm using right now are almost a decade old.
 
Thank you all.
But I didn't get my answer.


I'm not arguing about turning SWAP off or on (I believe turning SWAP off on the production server is totally craziness, with risk of breakdown; It's a security risk!!, On a Desktop Computer with 4GB of ram I never used SWAPPING, because I'll get better performance, even when playing games, But for a server the story is different [when they face memory leaks].).


Code: 
I know generally the performance of SWAP Partitions are better than SWAP Files, 
specially if they resides on the beginning of the disk.

But inside an VMWare VPS, does this matter? Since that VMWare Virtual Disk simply is a file??

The original question is:

Is there any huge performance difference between SWAP Files and SWAP Disks inside VM??



Code: 
Are you serious? swap is crap.
If your OS ever touch swap, buy more RAM, if your OS does not touch swap buy even more RAM 

If you want your HDD(or SSD) to die fast, just continue to use swap ...

In my case this didn't work. Because for now I only have 2 Websites with maximum 100 Hits/PerDay on that VPS and I did not want to spend 5/6 times more money to get a fully loaded dedicated server with huge amounts of ram. But even if I have a dedicated server with infinite RAM I'll enable at least 2 GB swap partition on it as mentioned above.
 
Probably, because the OS inside the VM still has to do its own filesystem management (on top of any such overhead for the host OS). As to whether it is significant is beyond my urge to test things out. I will say that if you're not hitting swap, or if most of the pages in swap are just sitting there (my laptop with 4G of RAM will sometimes swap out unused getty(8) processes, which then sit there until I reboot) then the performance difference between the two options is probably so close to zero as to be meaningless, whereas the flexibility of the swap file is likely more useful.
 
Probably, because the OS inside the VM still has to do its own filesystem management (on top of any such overhead for the host OS). As to whether it is significant is beyond my urge to test things out. I will say that if you're not hitting swap, or if most of the pages in swap are just sitting there (my laptop with 4G of RAM will sometimes swap out unused getty(8) processes, which then sit there until I reboot) then the performance difference between the two options is probably so close to zero as to be meaningless, whereas the flexibility of the swap file is likely more useful.
Click to expand...

tnx!!
 
You must log in or register to reply here.
Back
Top