Introduction to Linux Swap.

About Linux Swap for Ubuntu 14.04 LTS

Usage of virtual memory is supported in Linux systems. It is used as an extension to the normal RAM, and is established on a defined part of the hard drive. When a system is experiencing a shortage of RAM, i is possible to temporarily move some of its data from RAM to Swap. Usage of a separate file in need of swapping in these circumstances will be covered in this guide. Keep in mind, however, that a whole disk partition could be created and dedicated to this purpose, it's just that it is less flexible and requires some planning.

In general, Swap would be a great replacement for traditional RAM if only the hard drive wasn’t the slowest device in the system. If a system runs out of memory and some processes are kept in Swap, the result is that they will be slower.

How much disk space do you need to set aside for swap?

There is a rule of thumb that you should use as minimum compliance criteria:

The amount of memory allocated to Swapshould not be larger than the volume of RAM you physically have. An older recombination, the borderlines Unix/ Linux forum urbanmyth status states that states that swap space should be twice the available RAM, depending on how much HDD you have on a given system. In reality, you need as much Swap Space as your system will use, which is likely to be very little with most modern hardware setups. The only disadvantage of more Swap Space than you might need is the  finite nature of the HDD disk space allocated, which in most cases with large drives means the disadvantage is minimal.

Examples of RAM, hard drive and Swap Space:

With as much as 512MiB RAM and 30GB of hard disk space available, recommended Swap Space is 512MiB.

With as much as 512MiB RAM and 100GB HDD space, reserve 1GiB Swap since RAM volume is more limited compared to hard disk space.

With as much as 2GiB RAM and 30GB HDD, reserve 1 GiB for Swap (half the amount of RAM).

With as much as 2GiB RAM and 100GB HDD, you can use as much as 2GiB for Swap.

The actual state of Swap on your server

Use the command:

# swapon –s

to scan for any default Swap files enabled on the system.

If no Swap files exist you should see an empty list:

Filename            Type        Size    Used    Priority

Once it is confirmed there are no Swap files enabled on the virtual server, you should check how much space you have to work with on the VPS with a standard df command (-h flag puts the information in human readable format).

$ df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda3        29G  4,9G   23G  18% /

none            4,0K     0  4,0K   0% /sys/fs/cgroup

udev            986M   12K  986M   1% /dev

tmpfs           200M  1,1M  199M   1% /run

none            5,0M     0  5,0M   0% /run/lock

none            996M   76K  996M   1% /run/shm

none            100M   36K  100M   1% /run/user

In this example, a Swap file of 512MB will be created on a server with 23GB of space  available from 30GB disk. Thus, it is possible to proceed.

Design the Swap file

As with the other tasks, we start by creating a new file:

Create the Swap file using the dd command:

# dd if=/dev/zero of=/testswap bs=1024 count=512k

This command is quite standard but don’t forget the following line:

of=/testswap

This syntax sets the file’s name to ‘testswap’but you can assign any name you require. Once you have run the command, the system may be silent for a while - sometimes it needs a bit of time.

 

Our next step is setting up a Linux swap area:

# mkswap /testswap

Setting up Swap Space version 1, size = 524284KiB

no label, UUID=a527ab2b-12d4-49a8-92ee-fe51fa9646c0

To complete the operation, activate the Swap file:

# swapon /testswap

The Swap summary should display the new file.

# swapon -s

Filename Type Size Used Priority

/testswap file 524284 0 -1

Please note!If you stop here the file will get scraped during the next machine reboot.

You will need to edit the fstab file to mount it permanently on the virtual private server.

# nano /etc/fstab

Paste the following line at the end of the file:

/testswap none swap sw 0 0

Save and close the file (F3, Enter, F2).

Configure Swappiness

Swappiness is a programmable setting provided by the Linux kernel which controls how often the Swap file is used,. A swappiness setting = zero will mean that the Swap usage will be avoided unless absolutely necessary (where there is a risk of running out of memory altogether), while a swappiness setting of 100 will force programs to be swapped to disk almost instantly.

Ubuntu system comes with swappiness default value = 60, meaning that Swap will be used when memory usage is around 1/2 of available RAM. Check your system's swappiness value by executing:

$ cat /proc/sys/vm/swappiness

60

You may decide to turn that down to 10 or 15 to balance speed and safety The Swap file will only then be used when RAM usage is around 80 or 90 percent. To change the system swappiness value, open /etc/sysctl.conf as root:

# nano /etc/sysctl.conf

You can then change or add the value on the file:

vm.swappiness = 15

This will turn your Swap into an emergency buffer that should keep your system safe from crashing if you suddenly run low on memory.

Save and exit the file, then reboot for the changes to take effect.

We recommend spending a bit of time to set things up properly, as skipping swappiness will most likely result in poor performance.

As an extra precaution you can limit permission levels on the Swap file by running:

# chown root:root /testswap

# chmod 0600 /testswap

With this done, security measures are taken care of.

Enlarging potential – WordPress migration to a cloud server

Cloud vs Shared Hosting, For Ubuntu 14.04 LTS

One of the most noticeable advantages of cloud servers in general is resource availability, meaning you always get what you pay for. They are reliable, stable and efficient when handling websites and blogs with high traffic. While shared hosting is slightly cheaper, it simply cannot promise stable resource availability as these websites and blogs precisely because they are shared. This tutorial aims to help you through a migration of a WordPress blog/website. The process should take a few hours and should help you avoid any downtime.

Data Backup

It is good practice to have data backed up before carrying out any changes to the system. In this case, a full file backup along with MySQL backup is required. Hosting companies usually provide controlling software which helps make server management a bit more intuitive. We’ll be using cPanel for our example.

To create a file backup, simply copy folder “wp-contents” from your server to a secure place (your desktop, external HDD, or even a USB stick). During migration you will need to upload it to a cloud server with no changes to your blog structure. Just archive the folder (export to a zip file), then download it as soon as it’s generated. This way it’s less likely the file will get corrupted. Easy as that.

Another part of this section is to perform a database backup which can also be done quite easily using GUI software:

From cPanel, go to "Backup Wizard > MySQL Databases".

MySQL Backup

MySQL databases are usually exported in the *.sql.gz format.

Export the back up as mysql_backup.sql.gz to the same location as your “wp-contents” archive.

Backup Wizard

Compress

NB! Prerequisites:

LAMP stack installed on the new server.

Once your virtual private server is set up, you can start adding WordPress dependencies to form a LAMP stack:

  •         MySQL
  •         PHP Framework
  •         web server (we’re using Apache as the most common for WordPress builds)

Installing WordPress

Now everything is ready, you’ll need to install WordPress onto the server. The WordPress download section will link to the latest version from the main site, and installation is fairly straight forward. If you do have any problems there are plenty of guides online dedicated to setting up WordPress. This guide will only cover the migration process, but we might add one at a later date.

Configuring Virtual Host

You’ll need a new apache virtual host to handle the WordPress blog after you migrate the files.

First step:

To create a fresh file use the command:

# nano /etc/apache2/sites-available/example.com

Add a virtual host (use your own details instead of example.com and username).

<VirtualHost *:XX>

ServerName xxxxx.xxx

DocumentRoot /xxx/xxx/

</VirtualHost>

Let’s break down what you’re doing:

Every <VirtualHost></VirtualHost> black, signifies a separate virtual server.

The number next to the opening of each block *:XX indicates the port number that Apache will

be listed on.

ServerName is simply your domain name

DocumentRoot is the location for toe the Root of your WordPress directory.

<VirtualHost *:80>

ServerName example.com

DocumentRoot /var/www/

</VirtualHost>

<VirtualHost *:80>

ServerName www.example.com

Redirect permanent / http://example.com/

</VirtualHost>

Use the Apache utility ‘a2ensite’ to flip the on-switch for the created virtual server. It will use the new configuration and tell Apache to listen for your domain.

# a2ensite example.com

Any changes in server configuration will require you to reload the server to apply those changes. So reload it now:

# service apache2 reload

The actual migration — upload MySQL database and file contents to the VPS

WordPress is now set on the cloud server meaning that all the data from the old hosting environment can be moved over. First, upload the MySQL backup and web-content archives.

SCP is used to copy files among hosts over the network.

SSH protocol is used for transfers to apply a layer of security and authentication to the process. While it might sound complicated, SCP is easy to use and a very handy tool. To transfer a file you will need to input the file location on the hard drive and the recipient server details for the file transfer.

Use this example as a template for the command you'll need to run, you’ll need to execute it on the device storing your blog files to transfer it to the cloud server. Remember to keep a colon (:) at the end of the command:

# scp ~/Desktop/mysql_backup.sql.gz username@server_ip_address:

# scp ~/Desktop/wp-content.zip username@server_ip_address:

Restoring the database

You’ll need to log in to the server and define database_user, database_name with your details for this command in order to restore the database.

# mysql -h localhost -u database_user -p database_name < mysql_backup.sql.gz

You may need to specify a few other things in the command so let’s look at it a bit closer:

-h flag specifies the host address: leave it as localhost if the database is on the same VPS

-u flag is for the database username: database_user that you always need to specify

-p means that you will be required to provide in a password once prompted.

The last part is simply one name of the database backup file.

Once you execute this command, you will need to provide a password for the database user. After that the database backup contents will be imported to the new database_name on the VPS.

Restoring wp-content files

To restore your WordPress site to its pre-migration state, you’ll need to extract the zip archive you created with the unzip command.

That should extract and merge the stored content - ie themes, images, plugins etc with the wp-content structure - on your vps server.

# unzip wp-content.zip -d /var/www/

Verifying the results

You’ll need to run a few tests to make sure everything is running smoothly on the new server.

If you don’t come across any errors during this stage you should be able to migrate the site with no downtime at all.

First, upload your hosts file using this command line:

# nano /etc/hosts

Add this line to the end of the hosts file on your local computer

You’ll know that it’s working as it should if visiting example.com, will point you to your new server, but this should work only for your local machine. This will make testing a lot safer.

server-ip-address                             example.com

Do not forget to replace server-ip-address by the actual ip address of your VPS. Next, clear your DNS cache to apply settings of a hosts file configuration:

# service nscd restart

At this point everything should be working from your local machine. Once you type in your blog’s address, like example.com in the browser, you should see your blog as if it was never moved. If something is wrong, carefully go through the instructions again and perform some troubleshooting. Once you’re happy with the test, return the hosts file to its default state.

DNS settings renewal

The last step – you’ll need to update DNS settings via your domain registrar.

The ip of your new server goes in the A record

DNS always takes a while to update (up to 24h) during that time your site will continue to be served from your OLD hosting provider, so make sure you don’t cancel prematurely or don’t rush in to changing your new server settings if the site suddenly goes down.