My son’s school is offering a programming class. After my first introduction to Linux we had fun with the echo command and wrote a script that would say “Hi Fart” he was keen to learn more. He’s too young to attend the class. Instead, he has continued his journey learning Linux with me. It thought it would be hard to top “Hi Fart,” but apparently not.
I started our second lesson introducing him to the idea of the directory structure. We focused on his bedroom and tried to visualize that as /. I told him about /usr, /var, /, /etc. but that wasn’t holding his attention, I was losing him.
I decided to try something interactive. I told him about Change Directory — cd and List — ls, how they were similar and how they were different. Then, we played Linux. Starting in his room we cd-ed — changed directories — to the living room. Then we wanted to see what was in my bedroom, so we ls-ed the bedroom, peaking through the doorway without entering and listing the contents. We then ran around the house cd-ing and ls-ing the various rooms to see what was in them. It was great fun.
Next, I introduced him to some basic file manipulation commands — cat, less, and more — and we visited with our old friend echo. We again played the cd game and this time we would cat, less, and more the various objects in a room to see what was inside of them. We cd-ed into my bedroom and cat-ed the bed, dumping the contents on the floor to find pillows, sheets, and mommy, she was playing along! Then we more-ed his drawers, looking at drawers — pages — one at a time and seeing their contents. We then used less on his toy cubbies and scrolled through each cubby, back and forth, looking through his toys. I explained that you can add things to a file by using the echo command, so he decided he wanted to add a hug to the bed file for mommy.
“Hug” >> bed
>> adds content to a file and > replaces the content of the file so we cd-ed rooms again, this time to the bathroom, and demonstrated echo-ing to empty a file. This time the toilet was the file and emptied it via flushing:
“ “ > toilet
We discussed more and less and how they were different than cat and one another. I demonstrated this by using his toy shelves, which are divided into three rows of three cubbies for little drawers. To demonstrate cat we pulled all of the drawers out and saw only the last row of toys. Then for more I opened the first row of shelves only and we progressed through his toy drawers one row at a time. Then for less we did something similar, pulled open the first row, but then we also opened individual drawers as we progressed forward and backwards through the file.
I was able to turn learning Linux into a game that my son enjoys. He occasionally asks if we can play the Linux game and I of course oblige. I’m still not sure how I was able to top echo “fart,” but the Linux game is off and running. Can’t wait to see commands I can add next.
Editor’s Note: As third-party software, ServInt does not support node.js beyond installation. Also, to follow these instructions, users must have a working knowledge of the command line. Click here if you would like more information about logging into your server on the command line.
The first thing that you will need to do is download the latest version from nodejs.org:
Before proceeding further, you will need to make sure that you meet the following requirements listed in the README file: Read more
With Google’s decision to sunset SHA-1 SSL certification many clients have inquired about re-issuing SSL certificates in SHA-2 format. For the validity period of the certificate, we are able to re-issue certificates which were purchased through ServInt.
If you’ve purchased a one-year certificate and have six months left until your certificate expires, we’ll be able to issue a new certificate in SHA-2 format for the remaining six months. We are also able to add the remaining months on your current certificate to a new order. For example, if you have two months left on a certificate and wish to purchase a certificate for next year, we can issue a new certificate covering the next 14 months. Read more
Shellshock is a newly found vulnerability in Bash, the most common application allowing users to execute commands on Linux machines. It’s the environment within which commands are executed – the “shell”. There are a variety of shells available in the *NIX world, but Bash is by far the most common in Linux. Read more
There are more uses to these proprietary server analytics than simply ensuring that you’re receiving all of your critical system resources. Let’s take a moment to look at some of the most common ones.
1. Checking your site performance
The stated purpose of the Site Performance Guarantee resource graphs is to show that you are receiving your promised resources. If you see your site performance degrading, it’s very simple to check your resource graphs and make sure you are receiving 100% of your critical server resources.
Resource degradation, though, is so unlikely that not only could we not find an example of it to show you, we could not find an accurate way of artificially producing the problem for illustrative purposes.
The important point to remember when checking for hardware degradation is to make sure you look at the “Allocated” number in individual resource graphs. If that number falls below your guarantee for even five minutes, you qualify for a refund of that entire month of service. The important point to note here is that for each of our guaranteed resources — CPU, RAM, disk space and IOPS — if your site slows down and you do not know why, you can check these resources at any time to confirm that it is not a problem with the hardware. If it is — you get that month of hosting absolutely free. If you want the fine print, you can read our entire SLA here.
2. Monitor your total server uptime
With ServInt’s SolidFire SSD VPS, full server downtime is very unlikely in all but the most dire circumstances. Still, let’s look at what a full server outage would look like in your resource graphs. We simulated an outage on August 25th by rebooting a test server. Notice that the lines on the graph simply disappear. If you see this, click into a specific resource graph (such as CPU): You can see in this graph that not only has the resource utilization gone to zero, but the allocated amounts have as well. This indicates that the server itself was offline.
In the extremely unlikely event that you are temporarily unable to access the Portal, please know that these graphing tools will continue to collect data. This will be valuable after the incident should you decide to seek a refund for downtime.
3. Monitoring resource usage.
Confirming that your server hardware is running at 100% efficiency and your server is up are both important, but frankly, we don’t expect many customers to find evidence of resource degradation or downtime.
What is far more common is for customers who are experiencing site slowness to log into their resource graphs and find that their server is online and they are receiving all of their promised resources, but that they are using all the resources in one or more categories. Let’s look at some examples of this. These examples show customers who are maxing out IOPS, CPU and RAM respectively. Simply put, if you are using all of the resources your server has been allocated and you then wish to use more, your site will slow down. The question of how to fix this is one of time or money: should you optimize your code or purchase more server resources. Sometimes customers only have spikes in their resources. These spikes may have been anticipated or may be a surprise. The questions to consider in this scenario are: Did you have enough computing power in reserve to handle this extra traffic, and was the traffic spike preventable or simply a result of increased visits to your site?
Finally, there is a special circumstance when monitoring RAM usage on your ServInt SolidFire SSD VPS. There are two separate RAM metrics that add up to Total RAM: Active and Cache RAM. Active RAM is just what you would expect — this is the RAM the processes on your server are actively using.
Cache RAM is an optimization wherein unused RAM is temporarily used to store (or cache) data that has been recently accessed on the server. When that RAM is needed for Active RAM, the cache is simply dumped (or a portion is dumped) to free up the RAM. Some servers have a large cache because of many active users. In this case, the Active and Cache RAM total nearly all of the allocated RAM. But other servers do not require a large cache or the cache has been recently dumped due to the need for more active RAM. If your active RAM usage increases to near the limits of your allocated RAM, you will have little-to-no space left for Cache RAM. Depending on your configuration and requirements, this could signal a need to optimize your code or upgrade your hardware.
4. Planning for future optimizations or upgrades
One of the best ways to use your ServInt SolidFire SSD VPS resource graphs is to plan for future growth of your sites. Monitoring resource usage over time and deciding on predetermined limits past which you will upgrade can save you the headache of running out of resources in the first place.
Study your resource graphs. Determine how much of your system resources you’re using on a regular basis and how much you need to hold in reserve for growth or spikes in traffic. This will help you know when it is time to scale before you run out of resources. With ServInt’s SolidFire SSD VPS, knowing when to upgrade your resources has never been simpler.
Editor’s note: A reader made the following comment on yesterday’s blog post about our SolidFire Site Performance Guarantee and resource graphs: “I am curious to know what’s proprietary about these graphs given that so many open source tools exist (Munin, MRTG, Nagios etc.) that show similar stats.” We’ve asked one of the chief architects of ServInt’s resource graphing tools, Giles Fox, to weigh in.
From an engineering perspective, there’s nothing in particular that makes our graphs proprietary. For the most part, all of that same information can be polled by any user of the system, except — potentially — some of our IOPS data. Also, extrapolating the CPU data using open source tools involves a lot of complicated calculations. Still, if one wished, one could use Munin, MRTG or any of a number of other open source solutions to build their own graphs. Read more
You’ve heard us talk a lot about what makes ServInt’s SolidFire VPS and dedicated hosting platform the most significant evolution of Cloud hosting technology in many years — the elimination of noisy neighbors, the transition to an all SSD cloud storage solution, and most recently, the implementation of a hosting-industry first: a Site Performance Guarantee that promises your site will never slow down because of a drop in available RAM, CPU, disk or read write operations per second (IOPS).
What is behind this guarantee — and the verification and proof that you’re receiving the performance you’ve been promised — is the proprietary analytics tool that we’ve introduced to support our Site Performance Guarantee.
If you’re a SolidFire customer, these resource graphs are available in your ServInt portal. They give you total transparency into all your critical server resources, showing not just how much CPU, RAM, disk, IOPS, and network resources you’re using, but also tracking how much you’re guaranteed and currently allotted.
Never before has a virtual server been so transparent.
So, just what do these graphs include? Read more
If you’re a ServInt SolidFire customer, your site will never slow down because of your server. Ever.
Did you know that? Have we done a good job explaining that to you? I wonder sometimes.
In past blog posts, we’ve examined IOPS, resource contention, disaster recovery, and lots of other very good reasons why you should choose our SolidFire-powered VPS and dedicated servers. But when you boil it all down, the main reason is this:
If you’re a ServInt SolidFire customer, your site will never slow down because of your server.
That’s revolutionary — and it’s a genuine first for the business-focused hosting industry. No other hosting company can make this promise.
Now, as of today, we’re backing our promise up with a revolutionary new guarantee — ServInt’s SolidFire Site Performance Guarantee — that says this: if your site slows down because your server doesn’t deliver 100% of the CPU, RAM, disk and IOPS you were promised, for more than five minutes… you get your entire month of hosting absolutely free.
How will you know whether you’re getting all the server resources you deserve? By using our new, completely transparent system resource graphs — another ServInt exclusive. From this day forward, if you’re a SolidFire customer, we’re not just going to tell you exactly how much RAM, CPU, disk and IOPS you’ll get with each hosting package. We’re going to put tools into your hands to keep us honest — tools that will give you real, verifiable proof that your server is delivering what you paid for — and we’re going to back it all up with the most radical system resource guarantee in the hosting industry.
Here’s the punchline: ninety-nine-point-whatever percent server “uptime” guarantees are a thing of the past. As of today, ServInt is guaranteeing server performance — i.e., guaranteeing that your site is not only up and online, but also that your site or app performance is never compromised by any server resource shortcoming. Ever. We’ll prove it to you.
Editor’s Note: As third-party software, ServInt does not support Nginx beyond installation. Also, to follow these instructions, users must have a working knowledge of the command line. Click here if you would like more information about logging into your server on the command line.
Nginx offers an alternative to the Apache web server popular with some server admins. Advanced users may choose to run Nginx instead of Apache, as it is believed to offer possible performance benefits in certain configurations. Read on if you are interested in installing Nginx on a server running cPanel. Read more
There’s an interesting parallel between the way people buy web hosting and the way they buy sports cars. Frequently, the sports car purchaser who doesn’t actually compete in races will buy their vehicle based on theoretical maximum performance capability, examining numbers like top speed, maximum horsepower and so forth to see how fast their dream car might theoretically go.
Of course, people who actually race for a living understand a critically important maxim: top speeds don’t win races, high average speeds do. That means it’s just as important to be able to speed around accidents and slow traffic as it is to power down the straightaways as fast as possible.
It’s the same with hosting. The size of a CPU, the amount of RAM, the network uplink speed — these are all important metrics, but everybody’s working with similar engines these days. You can get your specs and never see reliable performance at other host because your server still can’t swerve around the accidents and slower traffic without getting bogged down. Why? Because of something called IOPS. Read more