Blog and websites hosted on a server were giving bad performance lately and the old SATA Hard Disk on the Lenovo Edge server seemed to be overloaded from In/Out operations and thus slowing down the websites opeining time as well as SQL queries (especially the ones from Related Posts WordPress plugin was quite slow. Sometimes my blog site opening times were up to 8-10 seconds.
To deal with the issue I obviously needed a better speed of I/O of hard drive thus as I've never used SSD hard drives so far, I decided to buy a new SSD (Solid State Drive) KINGSTON SV300S37A120G, 605ABBF2, max UDMA/133 hard disk.
Mounting the hard disk physically on the computer tower case wasn't a big deal as there are no rotating elements of the SSD it doesn't really matter how it is mounted main thing is that it is being hooked up somewhere to the case.
I was not sure whether the SSD HDD is supported by my Debian GNU / Linux so I had see whether Linux Operating System has properly detected your hard disk use dmesg
1. Check if SSD Hard drive is supported in Linux
linux:~# dmesg|grep -i kingston
[ 1.182734] ata5.00: ATA-8: KINGSTON SV300S37A120G, 605ABBF2, max UDMA/133
[ 1.203825] scsi 4:0:0:0: Direct-Access ATA KINGSTON SV300S3 605A PQ: 0 ANSI: 5
linux:~# dmesg|grep -i sdb
[ 1.207819] sd 4:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB)
[ 1.207847] sd 4:0:0:0: [sdb] Write Protect is off
[ 1.207848] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1.207860] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.207928] sdb: unknown partition table
[ 1.208319] sd 4:0:0:0: [sdb] Attached SCSI disk
Well great news as you see from above output obviously the Kingston SSD HDD was detected by the kernel.
I've also inspected whether the proper dimensions of hard drive (all 120 Gigabytes are being detected by the OS):
linux:~# fdisk -l /dev/sdb
Disk /dev/sdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Even better as the proper HDD sizing was detected by Linux kernel.
Next thing to do was of course to create ext4 filesystem on the SSD HDD.
I wanted to give 2 separate partitions for my Webserver Websites DocumentRoot directories which all lay under the standard Apache location inside /var/www as well as MySQL data folder which is also under the standard Debian based Linuces – /var/lib/mysql as the SQL data directory was just 3.3 GB size, I've decided to reserve 20GB gigabytes for the MySQL and another 100 GB for my PHP / CSS / JS / HTML and other data files /var/www.
2. Create SSD partitions with cfdisk
Hence I needed to create:
1. SSD partition of 100GB
2. SSD partition of 20GB
I have cfdisk installed and I believe, the easiest way to create the partitions is using interactive partitioner as CFDISK instead of fdisk: so in order to make the proper partitions I've ran
linux:~# cfdisk /dev/sdb
I' will skip explainig details on how to use CFDISK as it is pretty standard – display or manipulate disk partition table tool.
Just press on NEW button (moving with arrow keys buttons) and choose the 2 partitions size 100000 and 20000 MB (one thing to note here is that you have to choose between Primary and Logical creation of partitions, as my SSD is a secondary drive and I already have a ) and then press the WRITE button to save all the partition changes.
!!! Be very careful here as you might break up your other disks data make sure you're really modifying the SSD Hard Drive and not your other /dev/sda or other attached external Hard drive or ATA / SATA disk.
Press the WRITE button only once you're absolutely sure, you do it at your own (always create backup of your other data and don't blame me if something goes wrong) …
Once created the two partitions will look like in the screenshot below:
3. Create ext4 filesystem 100 and 20 GB partitions
Next thing to do before the two partitions are ready to mount under Webserver's files documentroot /var/www and /var/lib/mysql is to create ext4 filesystem, though some might prefer to stick to ext3 or reiserfs partition, I would recommend you use ext4 for the reason ext4 according to my quick research is said to perform much better with SSD Hard Drives.
The tool to create the ext4 filesystems is mkfs4.ext4 it is provided by debian package e2fsprogs I have it already installed on my server, if you don't have it just go on and install it with:
linux:~# apt-get install –yes e2fsprogs
To create the two ext4 partitions run:
linux:~# mkfs4.ext4 /dev/sdb5
…
linux:~# mfs4.ext4 /dev/sdb6
…
Here the EXT4 filesystem on partition that is supposed to be 100 Gigabytes will take 2, 3 minutes as the dimensions of partition are a bit bigger, so if you don't want to get boring go grab a coffee, once the partitions are ready you can evaluate whether everyhing is properly created with fdisk you should get output like the one below
linux:~# fdisk -l /dev/sdb
Disk /dev/sdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 63 234441647 117220792+ 5 Extended
/dev/sdb5 126 39070079 19534977 83 Linux
/dev/sdb6 39070143 234441647 97685752+ 83 Linux
4. Mount newly created SSD partitions under /var/www and /var/lib/mysql
Before I mounted /var/www and /var/lib/mysql in order to be able to mount under the already existing directories I had to:
1. Stop Apache and MySQL server
2. Move Mysql and Apache Documentroot and Data directories to -bak
3. Create new empty /var/www and /var/lib/mysql direcotries
4. Copy backpups ( /var/www-bak and /var/lib/mysql-bak ) to the newly mounted ext4 SSD partitions
To achieve that I had to issue following commands:
linux:~# /etc/init.d/apache2 stop
linux:~# /etc/init.d/mysql stop
linux:~# mv /var/www /var/www-bak
linux:~# mv /var/lib/mysql /var/lib/mysql-bak
linux:~# mkdir /var/www
linux:~# mkdir /var/lib/mysql
linux:~# chown -R mysql:mysql /var/lib/mysql
Then to manually mount the SSD partitions:
linux:~# mount /dev/sdb5 /var/lib/mysql
linux:~# mount /dev/sdb6 /var/www
To check that the folders are mount into the SSD drive, ran mount cmd:
linux:~# mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdc1 on /backups type ext4 (rw)
/dev/sdb5 on /var/lib/mysql type ext4 (rw,relatime,discard,data=ordered))
/dev/sdb6 on /var/www type ext4 (rw,relatime,discard,data=ordered))
That's great now the filesystem mounts fine, however as it an SSD drive and SSD drives are being famous for having a number of limited writes on disk before the drive lifetime is over it is a good idea to increase a bit the lifetime of the SSD by mounting the SSD partitions with noatime and errors=remount-ro (in order to not log file access times to filesystem table and to remount the FS read only in case of some physical errors of the drive).
5. Configure SSD partitions to boot every time Linux reboots
Now great, the filesystems gets mounted fine so next thing to do is to make it automatically mount every time the Linux OS boots up, this on GNU / Linux is done through /etc/fstab, for my 2 ext4 partitions this is the content to add at the end of /etc/fstab:
/dev/sdb5 /var/lib/mysql ext4 noatime,errors=remount-ro 0 1
/dev/sdb6 /var/www ext4 noatime,errors=remount-ro 0 1
quickest way to add it without a text editor is to echo to the end of file:
linux:~# cp -rpf /etc/fstab /etc/fstab.bak_25_03_2016
linux:~# echo ' /dev/sdb5 /var/lib/mysql ext4 noatime,errors=remount-ro,discard 0 1' >> /etc/fstab
linux:~# echo ' /dev/sdb6 /var/www ext4 noatime,errors=remount-ro,discard 0 1 ' >> /etc/fstab
Then mount again all the filesystems including the 2 new created SSD (100 and 20 GB) partitions:
linux:~# umount /var/www
linux:~# umount /var/lib/mysql
linux:~# mount -a
To assure properly mounted with noatime and remount-ro on errors options:
–
linux:~# mount | grep -i sdb
/dev/sdb5 on /var/lib/mysql type ext4 (rw,noatime,errors=remount-ro)
/dev/sdb6 on /var/www type ext4 (rw,noatime,errors=remount-ro)
It is also a good idea to check a statistics of disk free command:
linux:~# df -h|grep -i sdb
/dev/sdb5 19G 0G 19G 0% /var/lib/mysql
/dev/sdb6 92G 0G 92G 0% /var/www
6. Copy all Webserver and SQL data from backupped directories to new SSD mounted
Last but not least is to copy all original content files from /var/www-bak and /var/lib/mysql-bak to the new freshly created SSD partitions, though copying the files can be made with normal linux copy command (cp),
I personally prefer rsync because rsync is much quicker and more efficient in copying large amount of files in my case this were 48 Gigabytes.
To copy files from with rsync:
linux:~# rsync -av –log-file /var/log/backup.log /var/www-bak /var/www
linux:~# rsync -av –log-file /var/log/backup.log /var/lib/mysql-bak /var/lib/mysql
Then ofcourse, finally to restore my websites normal operation I had to bring up the Apache Webservers and MySQL service
linux:~# /etc/init.d/apache2 start
linux:~# /etc/init.d/mysql start
7. Optimizing SSD performance with periodic trim (discard of unused blocks on a mounted filesystem)
As I digged deeper into how to even further optimize SSD drive performance I learned about the cleaning action TRIM of the partitions for a long term performance proper operation, to understand it better think about trimming like Windows degrament operatin.
NAME
fstrim – discard unused blocks on a mounted filesystem
SYNOPSIS
fstrim [-o offset] [-l length] [-m minimum-free-extent] [-v] mountpoint
DESCRIPTION
fstrim is used on a mounted filesystem to discard (or "trim") blocks which are not in use by the filesystem. This is useful for
solid-state drives (SSDs) and thinly-provisioned storage.
By default, fstrim will discard all unused blocks in the filesystem. Options may be used to modify this behavior based on range or
size, as explained below.
Trimming is really necessery, otherwise SSD become very slow after some time. All modern SSD's support TRIM, but older SSD's from before 2010 usually don't.
Thus for an older SSD you'll want to check this on the website of the manufacturer.
As I mentioned earlier TRIM is not supported by all SSD drives, to check whether TRIM is supported by SSD:
linux:~# hdparm -I /dev/sdb|grep -i -E 'trim|discard'
* Data set Management TRIM supported (limit 1 block)
It's easiest to let the system perform an automatic TRIM. That can be done in several ways.
The quickest way for trimming is to place into /etc/rc.local trim commands, in my case it was the following commands:
fstrim -v /var/lib/mysql
fstrim -v /var/www
To add it I've used my favourite vim text editor.
Adding commands to rc.local will make SSD trimming be executed at boot time so this will reduce a bit the downtime during the trim with some time so perhaps for those like me which are running a crually important websites a better
An alternative way is to schedule a daily cron job to do just place a new job in /etc/cron.daily/trim e.g.:
linux:~# vim /etc/cron.daily/trim
#!/bin/sh
fstrim -v /var/lib/mysql
fstrim -v /var/www
linux:~# chmod +x /etc/cron.daily/trim
However the best way to enable automatic trimming to SSD is to just add the discard parameter to /etc/fstab I've already done that earlier in this article.
Not really surprising the increase of websites opening (page load times) were decreased dramatically web page loading waiting time fall down 2 to 2.5 times, so the moral of story for me is always when possible from now on to use SSD in order to have superb websites opening times.
To sum it up what was achieved with moving my data into SSD Drive, before moving websites and SQL data to SSD drive the websites were opening for 6 to 10 seconds now sites open in 2 to 4.5 seconds which is below 5 seconds (the normal waiting time for a user to see your website).
By the way it should be not a news forfor people that are into Search Engine Optimization but might be for some of unexperienced new Admins and Webmasters that, all that all page opening times that exceeds 5 secs is considered to be a slow website (and therefore perhaps not worthy to read).
The high load page times >5 secs makes the website also less interesting not only for end users but also for search engines (Google / Yahoo / Bing / Baidoo etc.) will is said to crawl it less if website is slow.
Search Engines are said to Index much better and crawl more frequently into more responsive websites.
Hence implementing SSD to a server and decreasing the page load time should bring up my visitors stats a bit too.
Well that's all for today, hope you enjoyed 🙂
, and then Enter to bring up the popup. 
