Tag Archives: linux

My Journey to Improve Disk Performance on the Raspberry Pi

 

I switched to Gluster FS a while ago to provide easier container mobility across my Raspberry Pi Docker Cluster. Gluster worked great and was easy to get up and running but I had very poor performance. The average write speed was about 1 MB/s which is unacceptable for a filesystem that will undergo a lot of writes. I decided that it was time to take action and started looking at kernel parameters that could be changed.

From researching performance over the years, I often came across the following settings and thought that this is the best place to start. Since the Raspberry Pi is not really made for performance, I did not think it was worth the time investigating additional settings.

Continue reading My Journey to Improve Disk Performance on the Raspberry Pi

How to use Cloud Explorer with Scality S3 server

I spent a few weeks searching for an open-source S3 server that I can run at home to test Cloud Explorer. I first came across Minio which is an open-source S3 server but I could not get it to work with Cloud Explorer because it had issues resolving bucket names via DNS which is a requirement using the AWS SDK. I then read an article about Scality releasing an open-source S3 server that you can run inside a Docker image. I was able to get Scality up and running quickly with little effort. In this post, I will explain how I got the Scality S3 server setup and how to use it with Cloud Explorer.

Continue reading How to use Cloud Explorer with Scality S3 server

Goodbye Docker on CentOS. Hello Ubuntu!

I have been a hardcore CentOS user for many years now. I enjoyed its minimal install to create a light environment, intuitive installation process, and it’s package manager. Docker is the most popular container format today and provides developers and enthusiasts with an easy way to run workloads in containerized environments. I started using Docker in production at home for about a year now for services such as Plex Media Server, Web Server for this blog, ZNC, MineCraft, and MySQL to name a few. A Dockerfile is a set of instructions used to create a Docker image. I invested many hours creating perfect Dockerfiles using CentOS and Fedora to make deployments simple on any operating system. However, a personal revolution was brewing.

Continue reading Goodbye Docker on CentOS. Hello Ubuntu!

Using LVM cache on Linux with a RAM disk

The Challenge

This is a follow up article from using a USB drive for a LVM cache. I decided to test things further by using a RAM disk instead of a USB drive.

 

The Journey

1. Create a RAM disk:

modprobe brd rd_nr=1 rd_size=4585760 max_part=0

2. Create the cache

pvcreate /dev/ram0
vgextend vg /dev/ram0
lvcreate -L 300M -n cache_meta vg /dev/ram0
lvcreate -L 4G -n cache_vol vg /dev/ram0
lvconvert –type cache-pool –poolmetadata vg/cache_meta –cachemode=writeback vg/cache_vol -y
lvconvert –type cache –cachepool vg/cache_vol vg/docker-pool

3. Run the DD test again

[root@tokyo /]# dd if=/dev/zero of=/tmp/1G bs=1M count=1000
1048576000 bytes (1.0 GB) copied, 1.89586 s, 553 MB/s
[root@tokyo /]# dd if=/dev/zero of=/tmp/1G bs=1M count=1000
1048576000 bytes (1.0 GB) copied, 1.79864 s, 583 MB/s
[root@tokyo /]# dd if=/dev/zero of=/tmp/1G bs=1M count=1000
1048576000 bytes (1.0 GB) copied, 0.922467 s, 1.1 GB/s
[root@tokyo /]# dd if=/dev/zero of=/tmp/1G bs=1M count=1000
1048576000 bytes (1.0 GB) copied, 1.33757 s, 784 MB/s

Average Speed: 736 MB/s

 

Conclusion

In Conclusion, my average write speed is 736 MB/s using LVM caching with a RAM disk. With a USB thumb drive, my average speed is 411.25 MB/s. With no cache, my average speed is 256 MB/s.

 

 

Using LVM cache on Linux

The Challenge

My home server uses a RAID 1 configuration. I was very disappointed in the performance and wanted to find a way to make it faster. After browsing the Internet one day, I came across news headlines that said CentOS 7  supports LVM cache. I found an old USB thumb drive and decided to take the cache challenge and see how it performs.

The Journey

Here is a simple DD test prior to enabling cache:

dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 6.27698 s, 167 MB/s

dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 5.04032 s, 208 MB/s

dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 3.41007 s, 307 MB/s

dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 2.94413 s, 356 MB/s

Average write speed: 256.5 MB/s

Time to enable caching and try to make the system perform better:

vgextend vg /dev/sdc

lvcreate -L 1G -n cache_metadata /dev/sdc

lvcreate -L 8G -n cache_vol /dev/sdc

lvconvert –type cache-pool –poolmetadata vg/cache_metadata vg/cache_vol

lvconvert –type cache –cachepool vg/cache_vol vg/original_volume_name

 

The write results with caching enabled:

# dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 3.73197 s, 281 MB/s

# dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 1.70449 s, 615 MB/s

# dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 3.91247 s, 268 MB/s

]# dd if=/dev/zero of=/tmp/1G bs=1M count=1000

1048576000 bytes (1.0 GB) copied, 2.18025 s, 481 MB/s

Average write speed: 411.25 MB/s

Conclusion:

When I originally built this machine from used parts on Amazon, I decided to reuse two old Western Digital Green drives which offer low performance and power usage.  I had no idea that they would perform poorly in RAID 1.  I was surprised and glad that a cheap USB flash drive helped me get a significant increase in write performance by an average of 155 MB/s. I find it fascinating how the Linux ecosystem helps people recycle old junk and put it to good use. Hooray.

 

Betting the farm on Docker

The Challenge

I wanted to try out Docker in production to really understand it. I believe that to fully understand or master something, you must make it part of your life. Containers are the next buzz word in IT and future employment opportunities are likely to prefer candidates with container experience. My current home environment consists of a single server running: OpenVPN, Email, Plex Media Server, Nginx, Torrent client, IRC bouncer, and a Samba server. The challenge is to move each of these to Docker for easier deployment.

The Journey

I noticed that many Docker containers contain multiple files that are added to the container upon creation. I decided to take a simpler approach and have the Dockerfile modify most of the configuration files with the sed utility and also create the startup script. I think that for most cases, having a single file to keep track of and build your system is much easier than editing multiple files. In short, the Dockerfile file should be the focal point of the container creation process for simpler administration.

Sometimes it is easier to upload prebuilt configuration files and additional support files for an application. For example, the Nginx configuration file is simpler to edit manually and have Docker put it in the correct location upon creation. Finally, there is no way around importing existing SSL certificates for Nginx in the Dockerfile.

Creating an Email server was the most difficult container to create because I had to modify configuration files for many components such as SASL, Postfix, Dovecot, creating the mail users, and setting up the alias for the system. Also, Docker needed to be cleaned often because it consumes large amounts of disk space for each container made. Dockerfiles with many commands took very long to execute. Testing out a few changes in a Dockerfile and rebuilding the container took a long time. Amplify that by the many containers I made and the many typos and you can see how my weekend disappeared.

After my home production environment moved to Docker and is working well, I created a BitBucket account to store all of my Docker files and MySQL backups to. There is a cron job inside the container that does a database dump to a shared external folder. If my system ever died, I can setup the new system easier by cloning the Git repository and building the container with a single command.

Conclusion

In conclusion, Docker was hard to deploy initially, but will save time in the future if disasters happen such as a system failure. Dockerfiles can basically be used as a well-documented blue print of a perfect application or environment. For continuity purposes in organizations, Dockerfiles can be shared and administrators should easily be able to understand what needs to be done. Even if you do not like Docker, you can basically copy and paste the contents of a Dockerfile with little text removal and build the perfect system.

Installing the official NVIDIA driver on CentOS

I found it very hard to find a guide to properly disable the nouveau driver so I can install the Nvidia driver on CentOS 6. This should help simplify the installation.

1. Install the kernel-devel and development packages for your running kernel.

yum -y install kernel-devel-`uname -r` kernel-headers-`uname -r`
yum groupinstall “Development Tools”

2. Blacklist the nouveau driver. This needs to be done to properly load the Nvidia driver. First, the module must be blacklisted on the system. The final step is to remove the nouveau driver from the kernel ram disk image.

echo “blacklist nouveau” >> /etc/modprobe.d/blacklist.conf

dracut -f -o nouveau

3. Boot into runlevel 3 with “nomodeset” on the kernel line in grub.cfg or add it to the kernel line in the grub boot menu. If you do not do this, you will see a black screen when you reboot.

4. Run the Nvidia installer

5. Reboot.

Installing the Nvidia driver on the latest Fedora

I found it very hard to find a guide to properly disable the nouveau driver so I can install the Nvidia driver on Fedora 20. This should help simplify the installation.

1. Install the kernel-devel and development packages for your running kernel.

yum -y install kernel-devel-`uname -r` kernel-headers-`uname -r`
yum groups mark-install “Development Tools”
yum groups install “Development Tools”

2. Blacklist the nouveau driver. This needs to be done to properly load the Nvidia driver. First, the module must be blacklisted on the system. The final step is to remove the nouveau driver from the kernel ram disk image.

echo “blacklist nouveau” >> /usr/lib/modprobe.d/dist-blacklist.conf

dracut -f -o nouveau

3. Boot into runlevel 3 with “nomodeset” on the kernel line in grub.cfg or add it to the kernel line in the grub boot menu. If you do not do this, you will see a black screen when you reboot.

4. Run the Nvidia installer

5. Reboot.