Hello. I'm Dean Campiglio
and welcome to Module 10. Lesson for and this lesson will be discussing how to monitor the resource usage of R V m.
So the last last time we talked about how we could allocate the resource is using resource pools and sub pools. Now we have to think about how we measure the performance of the V EMS after we've made those kinds of adjustments. And we have to also think about how we would make adjustments again in the future. Once once you've done some testing,
so we'll see what's involved with monitoring CPU, RAM disk and network.
This lesson will be in two parts of the second. Part of the lesson will go into a little bit more detail about the performance charts,
and then we'll wrap up our doing lab 17.
Okay, so when you're thinking about performance tuning,
you have to have, ah, reasonable methodology to follow.
We can't just start adjusting this in that and hope for the best
we need to do is pick appropriate tools to monitor the performance. You've got a lot of choices available depending on where you're doing the monitoring, whether it's on the host or the guest operating system or the VM itself.
These are different areas that give you
different perspectives on your resource usage and relative performance.
So once you can do some monitor and then you need to create a benchmark,
the reason we want to create a benchmark is so that you have
some baseline performance that you can refer back to. For instance,
on a particular day, you might look at your email server or your Web server, database server and charters performance throughout the day and get a rough idea
of how well it's doing. Is it is it staying in a reasonable range for resource utilization, or are you getting close to maxing out?
These are things you'd want to look at
once you've got an idea that this is a typical day, then that becomes a benchmark. You can save those charts,
print them out, or do other actions that you have something to refer back to.
Now we have to think about finding those areas where re sources are constrained or limited. In some way,
you could be limited with CPU. He could be a limited with memory, could be that your network connection is the problem or your storage
or a combination of those things. Once you've identified a resource that is experiencing limitations or its constrained in some way,
then we have to make some adjustments.
So in a general sense, you're trying to re balance
the allocation of resources.
If you remember from the last lesson, we were looking at reservations for for booting up machines, virtual machines. Maybe those reservations that you've chosen are not correct, that they're actually higher than they need to be.
So when you're when you're doing your measuring, you could determine that you had a reservation of 500 megahertz
and 5 12 megs of RAM, which are only using half that much so you can actually lower the reservation safely. Knowing that the VM should still be operational.
But you'll be using less resource is overall, thereby preserving some resource is for other V ems that are running on that host
reducing competition. What do we mean by this? What that means is that you're trying to
either movie EMS around to different hosts or a CZ part of a different type of load balancing,
or you're just adjusting the resource allocation.
So maybe you've got too many. Of'em is with high high requirements on the same host. It might make more sense
to move some of those vm somewhere else so that the ones that are on this host now
can operate with a little bit more breathing room and can use the resource is more effectively.
The last thing you need to think about here is documenting your changes.
If I'm if I create a benchmark and I've found resource is that need adjustment, I make the adjustments. I need to document what I did.
If you don't do this and you rely on your memory, you might have a problem down the line where now you've got another resource contention problem, and you don't remember what you change. Last time you don't recall
what was adjusted in order to improve the performance.
It's also a good idea to document the changes in case you need to reverse them.
You might have to go back in time to say, Well, way moved the memory down and we adjusted the processor down, but I don't remember how much. If you documented carefully, then you'll know
once you've created ah document showing the changes, then you have to update your benchmarks.
Because if I adjust my memory in just my processor of my network settings
now, I need to create a new benchmark to say that based on these new settings, this is the performance I'm expecting to get my CPU, my memory, our remaining in a range that's acceptable. I'm not getting too close to maxing out.
This is the kind of things you want to be able to
to document. And if you do this correctly, you should be able to produce a running tally of changes that you've made to your systems over time.
And this is really important so you can notice trends.
And if you need thio, provide justification to your management to say, Hey, we need to buy more memory for this host
or we really should buy a couple extra network cars for this host.
Or maybe we need faster storage.
Your manager right sable of How do I know that what you're telling me is true? You could say, Well, here is the proof. I've documented all the changes I've made. I'm doing the best with what I've got available, but it's still not enough. So that documentation will really help you.
All right. So what kind of monitoring tools should you be considering
If you're looking at your from the guest or west perspective, you have things that are built into every guest operating system, whether it's units or Lennox or windows.
We have the personal performance monitor perf mon the end, where tools has a perf mon dll that allows the virtual machine to access the host
CPU and RAM usage characteristics.
This is in addition to being able to look at the the performance characteristics of the guest OS as if it was running on physical hardware. So you could you could see that from a couple different scenarios there.
We also have something like i O meter, which will use when we do the lab. This congenital rate artificial io activity, or or another tool that will use generates artificial CPU activity.
I think that what we use is called CPU busier,
so this lets you simulate a heavy load on your system so you can see how your settings are working, and then you can apply that to the real world and make your adjustments as well
gaster west We also have the task manager.
This lets you look at memory network and CPU, and you can look at that over a relatively short period of time.
You can also go into the advanced mode of task manager if you have a more modern version of Windows
Window seven or Windows eight or Server 2012.
And the advanced version of Task Manager looks a lot more like Performance Monitor that you would normally be used to from earlier versions of windows like Vista or X P.
Thean were tools also provide some facilities for doing performance monitoring.
So we have our V Center performance charts.
These are really useful.
There's two different modes. You have the overview, which shows you of sort of a dashboard view of your processor memory disk network as some other things that are related to that. It's a pretty defined dashboard that you can
used to see at a glance how your virtual machine is performing or your host is performing,
and then the advanced view lets you drill down into more detail. Or I can look at CPU, for instance and see it all on Lee CPU related items. But then you can adjust the chart
options in order. Thio display just those statistics that you're interested in, and we'll talk about some of the statistics that you might want to look at a little bit later, in this lesson
of the center has the operations manager also lets you do some performance measurements.
We can look at the system logs for the SX I, the host itself
and within if you have a standalone host or if you wantto
connect to the host with with SS H, you can run the rez, ex top or yes, ex top.
And these are basically duplicates of the top command that you might find in a typical UNIX system. This is all text based, and it gives you a running tally of processes running on your system, how much processor they're using, how much memory they're using. And it updates itself every couple of seconds, depending on how you've gotta configured
fires. Other tools. I Perik is 1/3 party tool. You can use performance bond performance monitoring. There's dozens of Maur performance monitoring tools that are available. That's just one that you might want to investigate.
what do we do? What kind of questions. Do we have to ask when we're thinking about whether or not our resource is are constrained?
If you're looking at your seat for you
and it's continuously operating in a very high range, it's, you know, between 90 and 100% and it's always sort of staying at at that high level. You want to look at that from the guest, unless you wanna look at it from the VM point of view and also from the host point of view,
there's different perspectives for each of those, obviously the guest O s and the B M or more tightly linked.
But the host CPU needs to be monitored as well as you add more V EMS. You need to keep an eye on the host CPU performance to see if you've got enough capacity to be able to power on more of'em.
If your host CPU usage gets too high because you have too many of'em is running that you may be limited as to what you're able to expand on. You might have to
move some V EMS to another host in order to balance things out properly.
The virtual machine memory,
some of the things you want to think about here is whether or not you have a lot of balloon activity.
And when you look at the advanced,
uh, the advanced charts for memory, you can see that there's options to displayed
the, uh, the by default. It will display the balloon activity.
So if you see that you're ballooning,
meaning you're bothering memory from a lot of other V EMS. If that's has an upward trend and it's staying at a relatively high level,
then you probably have,
uh, not allocated enough memory for that V M.
We also have to think about whether or not the guest operating system is swapping.
If that's happening, that that means that this V M most likely is memory constrained
and your performance will really suffer under those circumstances.
And we have to look at the memory of the host itself, just like we have Ah,
CPU. We have to think about the host Ram
if their host begins swapping. That means that that you've overcommitted your memory
so I might have 10 v EMS
on. I want to use one gigabyte of ram each, but my host only has eight gigabytes of RAM.
Normally, that's okay,
because we expect that each of those 10 PM's will not use its full one gigabyte at any one time, so eight gigabytes might be enough to run. Under those circumstances,
however, there might be a case where all 10 G M's do need a gigabyte of RAM, and the host has no option at that point but to start swapping. So it's
changing memory pages and writing those two disc. And then when those need to be changing, retrieve them from disk and put some back into memory.
This allows the host to continue operating, but performance will definitely suffer.
Then we have to think about the active ram for virtual machine.
If the uh, the host Active Ram is increasing,
this is another consideration to think about. That means that the virtual machine memory is constrained. It's another indication of this,
but the active Ram is one of the parameters that you can display when you go into the advanced view and you look at your chart options. We'll explore some of that when we do the lab.
A virtual machine disc also might be constrained,
so one of the things we look at is whether or not to storage path has latent. See
the reading right rate could be examined. The reading right laden C could be examined.
These would indicate whether or not the virtual storage adapter is getting reasonable performance with the physical storage.
Two of the things you want to look at here would be the colonel Command late and see again, available under the Advanced Charts, Options and the Physical Device Command Leighton seat.
These are two parameters that you confined
to display and that will give you, ah, really good indication of whether or not the device is performing relatively well.
And lastly, we have to consider the Virtual Machine network performance.
Uh, one thing you want to make sure is that Veum, where tools installed that does give you access to the more advanced virtual network. Our drivers, if he and were tools, is not installed or it's not running
or it's out of date and corrupted somehow, then your virtual machine networking performance may suffer. So that's one thing you definitely want to check.
You also want to try to find a way to measure being with
between viens that are doing well on the one that the ones they're not doing well compare them a little bit. Measure the network band with
off for the physical adapters as well. It could be that your your physical network is suffering from congestion, and that's
showing itself by the PM's having troubles as well.
You also want to think about whether or not you're seeing a lot of retransmitted packets. Or if you have a lot of packets that are getting dropped,
these would be indications that your network is congested,
and the both ends of that communication are struggling to keep the information flow moving smoothly and steadily.
the methodology for performance turning, making sure that you can
pick the appropriate tools, create a baseline, make some adjustments, document those changes and then create another baseline update the baseline.
Then we know we've got various tools, whether it's the guest OS, the end where tools and related or something that's related directly to the host.
So learn the tools well practiced with them, and you should be able to drill down and find your performance problems more quickly.
And then if if you're looking for the resource Is that air constrained?
We've got some considerations for CPU and RAM on the host. See if you and RAM on the virtual machine and the network on the host and the networking on the virtual machine.
Okay, so stay tuned for part two. We'll talk a little bit more about performance charts.