Hello, and a big warm welcome to you to this Pluralsight module,
Troubleshoot Storage Issues.
My name is Andrew Mallett,
and I'm going to be your instructor helping guide you through the module
where we take a look at troubleshooting our storage devices.
Now that's going to be really looking at how we can measure our disk
operations and identify any bottlenecks that we might have.
We measure our disk access speed in IOPS or IOs per second.
We also need to be aware of the capacity,
how much space we have left on our devices.
Generally,
especially when we take a look at defragmentation where we're
looking at defragging our file systems,
we need to have no more than 80% of our disk being full.
We're also going to take a look at the mount options are
that are available within our file systems and moving
away from just using defaults.
By setting our own mount options,
we're certainly going to be able to change some of the
performance issues that we might be seeing.
When we take a look at IOPS,
it's our disk operation speed and it represents our IOs per second.
Now this is going to be affected by many different things,
such as the client application and how reads and writes are managed,
the disk controller that we are using and the different
devices that are plugged into that controller,
and the disk and the architecture of that disk that is being used.
When we take a look at the disk in disk controller making sure that
we have an SAS or faster controller and associated disks are going to
give us better applications than using, let's say,
a more commercial SATA controller and disk.
We'll also be taking a look at contention,
the way in which the data is being accessed,
who's accessing it.
We could also design our applications maybe to read data from one disk and
write it through to another disk so we can actually speed up our performance
by having data stored in different environments,
the data that needs to be read often and the data
that needs to be written too often.
When we're looking at measuring our raw IOPS,
it might be useful to add in the utility ioping.
Just in the same way as the standard ping utility can measure
our latency and speed across the network,
ioping is going to do the same thing to our disk devices.
So in Ubuntu, we can make sure that we've got it installed,
and then we can go through and say just ping our current directory.
Here, we're doing it for 20 occurrences.
If we just want to look at the data,
then we can go through and do a ‑R so we could actually just
view the data that we're getting back,
rather than the individual rights that will be
carried out by those 20 iterations.
If we elevate our privileges,
we can also send information with our ping through to raw disk devices.
With this, we've got an Ubuntu system that do have two disk drives.
There is no partitions on SDB, but elevating our privileges,
we can test the speed just to the raw disk device.
Now for us,
I think we need to find our command line and make sure that we can install
ioping and measure our speed to our current directory,
as well as to the second disk.
Come on, let's go through and take a look.
So as we dive out to our glorious command line,
we can see the sunshine on our Ubuntu 2004 system,
a system where we're going to start analyzing the
performance of our underlying block devices.
We're going to be able to start off by installing ioping,
so of course, it's going to be an apt install on Ubuntu,
but this is going to allow me to measure the speed of our devices
whether their file systems or raw disk devices.
I'm going to begin by working with our root file system,
and I can go through as a standard user ioping the current directory,
and then we get an infinite amount of these IO operations
being sent through to my current disk.
Now we can see then the requests going through and
counting up from the 1 through to 15, 16,
and so forth.
We can also then go through and just see the type
of request whether it's a slow, normal, or fast request that we're getting.
If I Ctrl+C on that,
we get a summary of those requests and then we can start seeing the averages,
and here, we're getting an IOP speed of 924 IOPs.
Now of course, we're only just getting started with ioping.
Just in our standard ICMP ping,
we can specify ‑c and the number of counts or
requests that we want to send through.
So here,
we're sending 20 requests so this will just go through and send 20 requests.
By default, they are separated by 1 second,
and again we can see then those requests going out,
and then we'll get the summary at the end much in the same way as
we did when we're doing it with our noncount,
but we don't have to do the Ctrl+C.
So we can see there that it sent out 19 requests,
and we can see then the summary of the speed.
Now if we want to go through and just look at that summary information,
we can still send our 20 requests through,
but if we add in the option ‑R, we just get the summary information at the end.
We can go through and do this a few times,
so we can go through and see over a period of time what
is the speed that we are getting.
We can also see as we're pinging these devices,
it's showing me this in the ext4 device on side of dev/sda1 so we can
understand where our root file system is that we're writing to.
Having our file system, though, is going to add a
restriction to the device access.
As an ordinary user, I can access raw devices,
but if I go through and use sudo and ioping to /dev/sdb on my Ubuntu system,
we do have a couple of disks, sdb doesn't have anything on it,
and as we go through and take a look, we've got 12.8000 IOPs.
When we go through 10.2, 15.4000, 20.1.
So we can see if we do this a few times,
we gain far greater speed to our raw device than when a file system is upon it.
Now this then becomes really critical when we start looking at our swap space.
If we set up virtual memory or swap memory on side of a raw device,
we can get faster access.
If we use a swap file, a file inside of a file system,
then we're automatically going to get slower access through to
that virtual memory so it becomes a real consideration when we're looking at setting up our swap space.